Ejemplo 8 de Informe

UNIVERSIDAD SIMN BOLVAR
Decanato de Estudios Profesionales

Coordinacin de Electrnica
Ingeniera en detalle del diseo e implantacin de una red de videoconferencia sobre IP
Por
Miguel Angel Yi Rojas
Sartenejas, enero de 2007

Por
Realizado con la Asesora de

Prof. Carlos Bianchi (Tutor Acadmico)
Lic. Carlos Rivera (Tutor Industrial)
Lic. Jess Mndez (Gerente de Proyecto)
INFORME FINAL DE CURSOS EN COOPERACIN TCNICA Y DESARROLLO

SOCIAL
Presentado ante la Ilustre Universidad Simn Bolvar
como requisito parcial para optar al ttulo de Ingeniero Electrnico

INFORME FINAL DE CURSOS EN COOPERACIN TCNICA Y DESARROLLO

SOCIAL presentado por
Miguel Angel Yi Rojas Carnet 0033484
REALIZADO CON LA ASESORIA DE:
Prof. Carlos Bianchi (Tutor Acadmico)
Lic. Carlos Rivera (Tutor Industrial)
Lic. Jess Mndez (Gerente de Proyecto)
RESUMEN
Este trabajo consisti en una ingeniera en detalle del diseo e implantacin de una red de
videoconferencia sobre IP. Para su ejecucin fue necesario identificar el sistema de
videoconferencia que se adaptaba a las necesidades del cliente, realizar visitas de inspeccin a
las localidades destinadas a ser salas de videoconferencia, instalar un nodo de prueba, elaborar
manuales de configuracin y protocolo de pruebas y, realizar cursos de introduccin al manejo
del sistema. Adems, el anlisis y verificacin de establecimiento de llamadas de
videoconferencia mediante capturas de trfico usando un sniffer. Se logr sentar precedentes
en la documentacin del diseo e implementacin de un sistema de videoconferencia IP a
travs de sistemas satelitales, as mismo, se lograron todos los objetivos planteados, se
hicieron las observaciones y recomendaciones en el desempeo del sistema, y la captura de
trfico de llamadas entre distintos terminales H.323.
PALABRAS CLAVES
Videoconferencia, IP, H.323, LAN, WAN, QoS
Aprobado con mencin:_______
Postulado para el premio:_______
AGRADECIMIENTOS
A DESCA C.A., por la oportunidad que me brind para realizar mi pasanta como proyecto
final de grado.
Al Lic. Carlos Rivera, Lic. Jess Mndez y Prof. Carlos Bianchi por las excelentes tutoras
que me ofrecieron.
A mi familia por la incondicional ayuda que recib en todo momento.
ndice General
_________________________________________________________________________
NDICE GENERAL
NDICE DE TABLAS
iii
NDICE DE FIGURAS
iv
NDICE DE FOTOS
vi
LISTA DE SMBOLOS Y ABREVIATURAS
vii
CAPTULO 1: INTRODUCCIN Y OBJETIVOS

1.1. Introduccin
1.2. Objetivo general
1.2.1. Objetivos especficos
CAPTULO 2: FUNDAMENTOS TERICOS

2.1. Definicin de videoconferencia
2.1.1. Tipos de videoconferencia
2.2. Protocolo de internet
2.2.1. Direcciones IP
11
2.2.2. IPv4
12
2.2.3. Clases De direcciones IP
13
2.2.4. Subredes (en ingls: subnetting)
14
2.2.5. Mscaras de subred
16
2.2.6. Mscaras de subred de longitud variable
16
2.3. Protocolo TCP
17
2.4. Protocolo UDP
21
2.5. Nmero de puertos TCP y UDP
22
2.6. Estndar de videoconferencia H.323
23
2.6.1. Estndar de sealizacin H.225
29
2.6.2. Estndar de control H.245
33
CAPTULO 3: VIDEOCONFERENCIA SOBRE IP

3.1. Diseo de una red de videoconferencia sobre IP
36
____________________________________________________________________________
Universidad Simn Bolvar
ndice General
ii
_________________________________________________________________________
3.2. Diseo e implantacin del sistema de videoconferencia sobre IP al CNTI
39
3.2.1. Identificacin de la plataforma de videoconferencia
42
3.2.2. Identificacin de la plataforma IP
42
3.2.3. Topologa de los nodos y diagrama de la red
44
3.2.4. Inspeccin preliminar y adecuacin de las salas
48
3.2.5. Instalacin del nodo de prueba
53
3.2.6. Aplicacin de calidad de servicio y distribucin de ancho de banda
60
CAPTULO 4: VERIFICACIN DE LLAMADAS DE VIDEOCONFERENCIA IP

4.1. Pasos de una llamada de videoconferencia IP
65
4.1.1. Captura de trfico de llamadas H.323
71
4.1.1.1. Captura de trfico usando terminales NetMeeting
71
4.1.1.2. Captura de trfico usando terminales cliente/servidor Beacon H.323
78
4.1.1.3. Captura de trfico usando terminales NetMeeting y el servidor Beacon H.323
83
4.1.1.4. Captura de trfico usando terminales NetMeeting y el codec Tandberg 6000 MXP 85
4.1.1.5. Anlisis de las capturas de trfico realizadas
91
CAPTULO 5: CONCLUSIONES Y RECMONEDACIONES

5.1. CONCLUSIONES
93
5.2. RECOMENDACIONES
94
REFERENCIAS BIBLIOGRFICAS
96
ANEXOS:
ANEXO 1: Fundamentos tericos sobre los estndares de data, audio y video
99
ANEXO 2: Requerimientos de las plataformas IP y de videoconferencia
120
ANEXO 3: Descripcin de los equipos de red y videoconferencia
124
ANEXO 4: Documento realizado para justificar el funcionamiento regular del sistema
138
____________________________________________________________________________
ndice de Tablas
iii
_________________________________________________________________________
NDICE DE TABLAS
Tabla 1: Estndares incluidos en el H.320
Tabla 3: Clases de direcciones IP
13
Tabla 4: Direcciones privadas
14
Tabla 5: Puertos que usan TCP y UDP
23
Tabla 6: Mensajes RAS
33
Tabla 7: Mensajes H.245
35
Tabla 8: Ubicacin de las salas de videoconferencia
40
Tabla 9: Puertos que usan los terminales H.323 durante una llamada de videoconferencia
(Terminal, MCU y Gatekeeper)
70
Tabla 10: Puertos que usa el codec Tanberg 6000MXP en una llamada punto a punto
70
Tabla 11: Puertos que usa el codec Tanberg 6000MXP en una llamada multipunto.
70
Tabla 12: Observaciones de capturas de trfico usando NetMeeting
76
Tabla 13: Observaciones de capturas de trfico usando cliente/servidor Beacon H.323
82
Tabla 14: Observaciones de captura de trfico usando NetMeeting y servidor Beacon
84
Tabla 15: Observaciones de captura de trfico usando NetMeeting y codec Tandberg
88
____________________________________________________________________________
ndice de Figuras
iv
_________________________________________________________________________
NDICE DE FIGURAS
Figura 1: Relacin de protocolos
Figura 2: Formato encabezado IPv4
Figura 3: Jerarqua de las direcciones IPv4
12
Figura 4: Formato y rango de direcciones IP segn la clase
14
Figura 5: Divisin recursiva de subredes
17
Figura 6: Intercambio de seales de tres vas
18
Figura 7: Formato encabezado TCP
19
Figura 8: Formato encabezado UDP
21
Figura 9: Arquitectura general de H.323
25
Figura 10: Terminales H.323
26
Figura 11: Red con Gateway
26
Figura 12: Uso del MCU
28
Figura 13: Arquitectura red H.323 y sus componentes
28
Figura 14: Llamada directa de sealizacin
30
Figura 15: Llamada de sealizacin enrutada por gatekeeper
30
Figura 16: Estructura del estndar Q.931
31
Figura 17: Formato de elemento de informacin de octeto unitario (tipo 1)
32
32
Figura 19: Formato de elemento de informacin de longitud variable
32
Figura 20: Escenario 1 (ambiente H.323)
38
Figura 21: Escenario 2 (Ambiente H.323-H-320)
38
Figura 22: Esquema general del sistema de videoconferencia
39
Figura 23: Mapa de Venezuela con la ubicacin de las salas de videoconferencias
41
Figura 24: Topologa nodo principal
44
Figura 25: Topologa nodo remoto o mvil
45
Figura 26: Topologa nodo porttil
45
Figura 27: Diagrama de la red de videoconferencia del CNTI
46
Figura 28: Diagrama del rack
47
Figura 29: Topologa de red que se quiere simular
54
____________________________________________________________________________
ndice de Figuras
_________________________________________________________________________
Figura 30: Topologa de red simulada
57
Figura 31: Captura de pantalla de los ping realizados en una prueba del laboratorio
59
Figura 32: Calidad de Servicio en codec Tandberg
62
Figura 33: Paso 1 (establecimiento de la llamada H.323)
66
Figura 34: Paso 2 (Flujos de Sealizacin de Control o Negociacin de Parmetros H.323) 67

Figura 35: Paso 3 (Flujo de rfagas de media y control de media H.323)
68
Figura 36: Paso 4 (Liberacin de la llamada H.323)
69
Figura 37: Identificacin de llamadas IP en el WireShark
72
Figura 38: Seleccin de llamadas IP en el WireShark
73
Figura 39: Aplicacin de filtro de pantalla en el WireShark
73
Figura 40: Informacin disponible en el WireShark (usando NetMeeting)
74
Figura 41: Traza de llamadas IP en el WireShark (usando NetMeeting)
75
Figura 42: Anlisis del paquete H.245 OpenLogicalChannelReject en la captura usando

NetMeeting
77
Figura 43: Captura de paquetes sin filtro de pantalla (usando NetMeeting)
78
Figura 44: Identificacin del producto con el que est realizando la llamada
80
Figura 45: Traza de llamadas IP en el WireShark (usando cliente/servidor Beacon H.323) 81

Figura 46: Informacin disponible en el Wireshark (usando NetMeeting y el servidor Beacon)
83
Figura 47: Traza de llamadas IP en el WireShark (usando NetMeeting y el servidor Beacon)
84
Figura 48: Informacin disponible en el Wireshark (usando NetMeeting y codec Tandberg)
86
Figura 49: Traza de llamada IP en el WireShark (usando NetMeeting y codec Tandberg),
llamada finalizada por el codec Tandberg.
87

89
Figura 51: Traza de llamada IP en el WireShark (Usando NetMeeting y codec Tandberg),
llamada finalizada por el NetMeeting.
90
____________________________________________________________________________
ndice de Fotos
vi
_________________________________________________________________________
NDICE DE FOTOS
Foto1: Rack instalado
48
Foto 2: Rack instalado
48
Foto 3: Sala destinada para videoconferencia (San Felipe)
50
Foto 4: Sala de conexiones (San Felipe)
50
Foto 5: Sala destinada para videoconferencia (Maracay)
51
Foto 6: Sala de conexiones (Maracay)
52
Foto 7: Sala acondicionada para videoconferencia
53
Foto 8: Conexin PC al router
55
____________________________________________________________________________
Lista de smbolos y abreviaturas

vii
_________________________________________________________________________
LISTA DE SMBOLOS Y ABREVIATURAS
ACK: Acknowledge (Reconocimiento)

ADSL: Asynchronous Digital Subscriber Lines (Lnea de Abonado Digital Asimtrica)
BRI: Basic Rate Interface
CLI: Command Line Interface (Interfaz de Lnea de Comandos)
DHCP: Dynamic Host Configuration Protocol (Protocolo de Configuracin Dinmica de
nodos)
DNS: Domain Name System (Sistema de denominacin de dominios)
EIGRP: Enhanced Interior Gateway Routing Protocol (Protocolo de Enrutamiento de
Gateway Interior Mejorado)
FDDI: Fiber Distributed Data Interface (Interfaz de datos distribuidos por fibra)
FTP: File Transfer Protocol (Protocolo de Transferencia de Archivos)
H.225: Estndar ITU de sealizacin de llamadas H.323
H.245: Estndar ITU de control de llamadas H.323.
H.323: Estndar que provee especificaciones para terminales, equipos de redes y servicios en
la comunicacin multimedia sobre redes que no proporcionan calidad de servicio.
HTTP: Hyper Text Transfer Protocol (Protocolo de Transferencia de Hipertexto)
IANA: Internet Assigned Numbers Authority (Agencia de Asignacin de Nmeros de Internet)
ICMP: Internet Control Message Protocol (Protocolo de Control de Mensajes de Internet)
IGMP: Internet Group Management Protocol (Protocolo de Manejo de Grupos de Internet)
IGRP Interior Gateway Routing Protocol (Protocolo de Enrutamiento de Gateway Interior)
IOS: Internetwork Operating System (Sistema Operativo de Interconexin de Redes)
IP: Internet Protocol (Protocolo de Internet)
IPRL: Intelligent Packets Lost Recovery (Recuperacin Inteligente de Prdida de Paquetes)
IPv4: Protocolo de Internet versin 4
IPv6: Protocolo de Internet versin 6
ISDN: Integrated Service Digital Network (Red Digital de Servicios Integrados)
IS-IS: Intermiate System Intermediate System (Sistema Intermedio Sistema Intermedio)
ISN: Initial Sequence Numbers (Nmeros de Secuencia Iniciales)
____________________________________________________________________________

viii
_________________________________________________________________________
ISO: International Organization for Standardizations (Organizacin Internacional para las
Estandarizaciones)
ITU:
Internacional
Telecommunication
Union
(Unin
Internacional
de
las
Telecomunicaciones)
Kbps: Kilo bits por segundo
LAN: Local Access Network (Red de Acceso Local)
MAC: Media Access Control (Control de Acceso a los Medios)
MAN: Metropolitan Access Network (Red de Acceso Metropolitano)
Mbps: Mega bits por segundo
MC: Controlador Multipunto
MCS: Multipoint Conference Server (Servidor de Conferencia Multipunto)
MCU: Multipoint Control Unit (Unidad de Control Multipunto)
MP: Procesador Multipunto
NAT: Network Address Translation (Traduccin de Direcciones en Red)
OSI: Open System Interconnection (Interconexin de Sistemas Abiertos)
OSPF: Open Shortest Path First (Abre el camino ms corto primero)
PCM: Pulse Code Modulation (Modulacin por Codificacin de Pulsos)
PRI: Primary Rate Interface
PSTN: Public Service Telephonic Network (Red Telefnica de Servicio Pblico)
QoS: Quality of Service (Calidad de Sevicio)
RAS: Registration, Admission and Status (Registro, Admisin y Estatus)
RFC: Request For Comments (Solicitud de Comentarios)
RIP: Routing Information Protocol (Protocolo de Enrutamiento de Informacin)
RSVP: Resource ReSerVation Protocol (Protocolo para la Reserva de Recursos)
RTCP: Real Transfer Control Protocol (Protocolo de Control de Transferencia en tiempo
Real)
RTP: Real Transfer Protocol (Protocolo de Transferencia en tiempo Real)
SDSL: Synchronous Digital Subscriber Lines (Lnea de Abonado Digital Simtrica)
SMTP: Simple Message Transfer Protocol (Protocolo de Transferencia de Mensajes Simples)
SNMP: Simple Network Management Protocol (Protocolo simple de administracin de red)
SYN: Synchronization (Sincronizacin)
____________________________________________________________________________

ix
_________________________________________________________________________
TCP: Transport Control Protocol (Protocolo de Control de Transporte)
TFTP: Trivial File Transfer Protocol (Protocolo trivial de transferencia de archivos)
UDP: User Datagram Protocol (Protocolo de Datagrama de Usuario)
VLSM: Variable Length Subnet Masks (Mscaras de Subred de Longitud Variable)
VoIP: Voice over IP (Voz sobre IP)
VPN: Virtual Private Network (Red Privada Virtual)
WAN: Wide Access Network (Red de Acceso Amplio)
____________________________________________________________________________
Captulo 1: Introduccin y objetivos

_________________________________________________________________________
CAPTULO 1: INTRODUCCIN Y OBJETIVOS
1.1. INTRODUCCIN:
Con la finalidad de alcanzar el proyecto final de grado, presenta este informe los resultados
de la pasanta realizada en la empresa DESCA C.A.. El objetivo principal fue la ingeniera en
detalle del diseo e implantacin de una red de videoconferencia sobre IP al CNTI (Centro
Nacional de Tecnologa de Informacin).
En vista de la necesidad del estado venezolano de implementar un sistema de
videoconferencia para interconectar diversas instituciones a nivel nacional, con el objeto de
lograr intercambios en las reas de Ciencia, Tecnologa e Innovacin, el Centro Nacional de
Tecnologas de Informacin (CNTI) y el Fondo de Investigacin y Desarrollo de las
Telecomunicaciones (FIDETEL), firmaron un acuerdo donde el CNTI se comprometi a
desarrollar el proyecto denominado Telecomunicaciones Masivas del Sistema Nacional de
Ciencia, Tecnologa e Innovacin, Mediante la Implantacin de una Red de Videoconferencia
y por su parte FIDETEL aprob el financiamiento para la ejecucin del mismo.
El CNTI inici un proceso de licitacin para seleccionar la empresa responsable del diseo
e implantacin de la red de videoconferencia; DESCA C.A. fue la empresa seleccionada.
DESCA C.A. (Desarrollos de Soluciones Especficas, Compaa Annima)
es un
Integrador de Soluciones de Redes y Telecomunicaciones especializado en el Ciclo de

Servicios completo de redes de clientes; que comprende diseo, implementacin, operacin,
optimizacin y/o mantenimiento. Gracias a su alianza estratgica con la empresa Tandberg,
est incursionando en el campo de la videoconferencia, ofreciendo soluciones integrales desde
el punto de vista tecnolgico, las cuales ofrecen una plataforma ideal para la optimizacin de
los negocios, por va del aumento de productividad y/o reduccin de costos.
DESCA C.A. es responsable de todo lo referente al diseo e implantacin del sistema de
videoconferencia, esto incluye el suministro de todos los equipos necesarios, su instalacin,
configuracin y mantenimiento, tomando en cuenta los requerimientos del cliente (CNTI)
____________________________________________________________________________

_________________________________________________________________________
quien fue responsable de definir la tecnologa de enlace satelital, entre otros aspectos. Es
importante destacar que es la primera vez que se implementa en Venezuela un sistema de
videoconferencia a travs de enlaces satelitales, y no existen referencias y/o recomendaciones
sobre el comportamiento del sistema, de ah la importancia de las documentaciones generadas
en este proyecto. Una vez finalizado el proyecto, se implementar un programa de
capacitacin y adiestramiento tcnico para cuarenta operadores de los sistemas de
videoconferencia, abarcando la teora de los sistemas de videoconferencia y el manejo de los
equipos incluidos en el diseo. Para el momento de redactar el presente informe, el proyecto
tena un avance aproximado del 70%, quedando por culminar la instalacin del nodo espejo, 7
nodos remotos y 3 unidades mviles.
Para la absoluta comprensin y correcto manejo de los trminos que abarca el tema de la
videoconferencia sobre IP, se realiz un levantamiento de informacin correspondiente a la
videoconferencia como tal, sus tipos y aplicaciones, el protocolo de Internet, el
direccionamiento, la divisin en subredes (manejo de mscaras de subred de longitud
variable), los protocolos y puertos que se usan. As como tambin, los estndares que abarca el
H.323, los cuales rigen el establecimiento de videoconferencias sobre IP.
Luego, para el diseo de una red de videoconferencia, se investigaron los puntos claves
que se deben tener en cuenta de acuerdo a las necesidades del cliente para una implementacin
exitosa, que satisfaga las partes involucradas con un alto rendimiento y al mejor costo. Para
este proyecto se describen las caractersticas del diseo, las plataformas que se implementaron,
las topologas de los nodos, diagramas de red y de rack. Con el diseo se realizaron
inspecciones a las localidades, instalacin de un nodo de prueba o laboratorio para simular y
probar el sistema, se configuraron los equipos, se estableci la calidad de servicio y se cre un
protocolo de pruebas. En base a los anteriores, se elaboraron manuales de configuracin y
pruebas a realizar durante la instalacin de los equipos.
Finalmente, se investigaron los pasos que se siguen durante el establecimiento de una
llamada de videoconferencia IP, puertos usados en los intercambios de paquetes segn los
estndares H.225 y H.245, para luego realizar capturas de trfico a llamadas reales con un
sniffer, y de esta manera verificar y analizar los paquetes que se intercambian en la prctica.
____________________________________________________________________________

_________________________________________________________________________
Para obtener muestras significativas y vlidas se realizaron capturas de trfico con distintos
terminales H.323.
1.2. OBJETIVO GENERAL:
Efectuar una ingeniera en detalle del diseo e implantacin de una red de

videoconferencia sobre IP, participando en forma activa durante todas las fases del proyecto
que implementar DESCA C.A. al CNTI (Centro Nacional de Tecnologas de Informacin),
denominado por ellos: Arranque del proyecto de Telecomunicaciones Masivas del Sistema
Nacional de Ciencia, Tecnologa e Innovacin, mediante la Implantacin de una red de
Videoconferencia
1.2.1. OBJETIVOS ESPECFICOS:
1. Realizar la documentacin tcnica de un diseo tipo de red de videoconferencia.

2. Desarrollar la documentacin tcnica del diseo e implantacin de la red de
videoconferencia que DESCA C.A. implementar al CNTI. Investigar e identificar
plataformas a usar en la solucin final (etapas del proyecto, tecnologa de enlace utilizada,
equipos utilizados, protocolos involucrados, diagrama de los nodos, diagrama de los racks,
conexiones a red, especificaciones de calidad de servicio y la capacidad del canal, pruebas
realizadas). Esta documentacin tiene la finalidad de servir de gua o plantilla para futuros
proyectos relacionados con videoconferencia sobre IP.
3.
Instalacin y configuracin de equipos o dispositivos en un nodo de prueba (maqueta en

laboratorio de DESCA C.A.)
4. Verificacin, medicin y anlisis de protocolos presentes en el proceso de una llamada en

videoconferencia real (maqueta) usando un sniffer para el anlisis de trfico, con la
respectiva documentacin de las pruebas realizadas.
____________________________________________________________________________
Captulo 2: Fundamentos Tericos

_________________________________________________________________________
CAPTULO 2: FUNDAMENTOS TERICOS
2.1. DEFINICIN DE VIDEOCONFERENCIA:
La videoconferencia es un servicio multimedia que permite la interaccin entre distintos

grupos de trabajo ubicados en puntos geogrficamente distantes en tiempo real. El servicio
consiste bsicamente, en interconectar mediante sesiones interactivas a un nmero variable de
interlocutores, de forma que todos puedan verse y conversar entre s(2). De acuerdo a la
tecnologa de videoconferencia, la aplicacin y el equipamiento utilizado, se puede disponer
de otras funcionalidades como:
Presentaciones PowerPoint: Un participante realiza una presentacin PowerPoint que el

resto de los participantes pueden seguir;
Pizarra electrnica: Pizarra donde cada participante puede presentar texto, grficos, etc.;
Proyector de documentos: Proyeccin de documentos impresos en papel; entre otras

funciones.
Algunos ejemplos en los que se emplea la videoconferencia son: reuniones ejecutivas,
educacin, cursos especializados, seguridad a distancia, conferencias, telemedicina,

diplomado, asesoras, seminarios, negocios, etc.
Con las videoconferencias, una reunin crtica toma slo unos cuantos minutos en
organizarse. Adems, estn siempre disponibles y previenen mal entendidos por
comunicaciones escritas u otros medios. Gracias a ellas, la informacin est actualizada, es
exacta y en tiempo real. Cancelar una reunin importante, adelantarla o aplazarla es muy fcil,
eliminndose de esta manera los problemas que esto acarrea al tener que cancelar compras de
pasajes a ltima hora, o reservar vuelos anteriores, etc.
2.1.1. TIPOS DE VIDEOCONFERENCIA:
La videoconferencia posee varias modalidades de transporte:
ISDN (Integrated Service Digital Network), en espaol Red Digital de Servicios

Integrados RDSI: Es capaz de soportar transmisin asncrona de datos y el ancho de banda
____________________________________________________________________________

_________________________________________________________________________
es garantizado una vez que se ha establecido la conexin. Con este servicio toda la
informacin como audio, datos y video es transmitida de forma digital a altas velocidades
sobre la red pblica de telefona conmutada (PSTN, sus siglas en ingls). Existen dos
conexiones ISDN, la BRI (Basic Rate Interface) y la PRI (Primary Rate Interface).
Bsicamente, la BRI provee dos canales-B de 64kbps y un canal-D de 16kbps mientras
que la PRI en Europa provee treinta canales-B de 64kbps y un canal-D de 64kbps(3).
En el pasado la mayora de las conferencias han sido entre dos participantes sobre ISDN, y
esencialmente con conexiones punto a punto. Sin embargo, la tecnologa multipunto ahora
permite que un grupo de personas participen en una conferencia y compartan informacin.
Para mantener una conferencia multipunto sobre ISDN, los participantes usan una unidad
de control de multipunto (MCU, sus siglas en ingls), que conecta y administra todas las
lneas ISDN. Este puede ser un MCU separado o un punto terminal con capacidad de
multipunto H.320.
El H.320 es estndar ITU (Internacional Telecommunication Union) para conferencias
ISDN e incluye los estndares que se muestran en la tabla 1:
Audio
G.711
G.722
G.722.1
G.728
Video
H.264
H.263
H.261
Data
H.239
T.120
Control
H.221
H.231
H.242
H.243
IP (conexiones LAN y WAN): Se utiliza una red de datos para intercomunicar los equipos
de videoconferencia. Al equipo se le asigna una direccin IP, similar a cualquier PC
(Computadora Personal) conectada a la red. Ocupa un ancho de banda slo cuando hay
una llamada y lo hace en forma dinmica. Puede operar al pasar por redes ATM o Frame
Relay.
Hoy en da la mayora de las compaas usan redes de acceso local (LAN, sus siglas en
ingls) de 100Mbps con switchs y routers, permitindoles tener suficiente ancho de banda
para soportar conferencias de escritorio. Las LAN ofrecen un ancho de banda
significativamente mayor que las ISDN, la calidad de video en una conferencia es mucho
____________________________________________________________________________

_________________________________________________________________________
mayor y puede aproximarse a calidad de televisin. Los avances de la tecnologa han

permitido tener comunicaciones de Gigabit Ethernet (1000 Mbps), switchs ms rpidos,
ADSL (Asynchronous Digital Subscriber Lines o Lnea de Abonado Digital Asimtrica),
SDSL (Synchronous Digital Subscriber Lines o Lnea de Abonado Digital Simtrica) y las
redes privadas virtuales o VPN, que han permitido incrementar y/o disponer de anchos de
banda seguros, mientras que el IP Multicasting (en espaol: multidifusin IP) ha reducido
las cargas en la red en conferencias que incluyen a ms de dos participantes.
A diferencia de las redes ISDN, las LAN y WAN (Wide Access Network) usan el protocolo
TCP/IP y el estndar H.323, el cual define cmo se estructura la informacin de audio,
video, datos y control (AVDC, sus siglas en ingls) en los paquetes IP. La mayora de las
compaas usan DHCP (Dynamic Host Configuration Protocol) y asignan direcciones IP
de forma dinmica a cada computadora. Por lo tanto, para identificar a los usuarios, el
terminal H.323 es registrado con un Gatekeeper y se llama a una conferencia por el alias
H.323 correspondiente. El Gatekeeper traduce este alias en su direccin IP
correspondiente(3).
Para mantener una conferencia multipunto sobre IP, el sistema H.323 requiere de un
Servidor de Conferencia Multipunto (MCS, sus siglas en ingls), tambin llamado como
Unidad de Control Multipunto (H.323 MCU), que no es igual al H.320 MCU.
El H.323 es un estndar ITU para las conferencias LAN e incluye los estndares que se
muestran en la tabla 2:
Audio
G.711
G.722
G.722.1
G.723.1
G.728
G.729
Video
H.264
H.263
H.261
Data
H.239
T.120
Control
H.225
H.245
Enlaces dedicados: Es una conexin permanente entre dos puntos, la velocidad de

comunicacin es constante. Este tipo de enlace es el ms tradicional y generalmente se
emplea fibra ptica, microondas o satlite. Si se requiere comunicacin con otros sitios, se
____________________________________________________________________________

_________________________________________________________________________
debe contar con un enlace para cada lugar. Actualmente no es comn que los clientes
soliciten estos medios de comunicacin ya que no es flexible en las conexiones.
2.2. PROTOCOLO DE INTERNET:
El Protocolo de Internet o IP es un protocolo de capa de red (capa 3 segn el modelo de

referencia ISO/OSI) no orientado a conexin usado tanto por el origen como por el destino
para la comunicacin de datos a travs de una red de paquetes conmutados. Este protocolo
contiene informacin de direccionamiento y de control que permiten que los paquetes sean
enrutados. El IP se encuentra documentado en el RFC 791 (Request For Comments) y es el
principal protocolo de capa de red en la suite de protocolos de Internet. A su vez, el IP junto
con el Protocolo de Control de Transmisin o TCP (Trasnfer Control Protocol) representan el
corazn de los protocolos en Internet (TCP/IP)(4). Toda la informacin TCP, UDP, ICMP e
IGMP se transmiten en datagramas IP. Una caracterstica importante de este protocolo, es que
proporciona un servicio de entrega no confiable y sin conexin (en ingls: connectionless).
Cuando se dice que se proporciona un servicio no confiable, se refiere a que no existen
garantas de que un datagrama IP llegue satisfactoriamente a su destino. El IP proporciona un
servicio de mejor esfuerzo (en ingls: best effort). Cuando algo sale mal, como un router
que se queda temporalmente sin buffer, el IP tiene un simple algoritmo de manejo de error:
desecha el datagrama y trata de enviar un mensaje ICMP (Internet Control Message Protocol)
al origen. Cualquier otro mtodo confiable debe ser proporcionado por las capas superiores,
por ejemplo: TCP.
Cuando se dice que se proporciona un servicio sin conexin, significa que el IP no
mantiene ningn tipo de informacin sobre los datagramas sucesivos. Cada uno de ellos es
manejado de manera independiente de todos los dems datagramas. Esto quiere decir que los
datagramas IP se pueden entregar fuera de orden. Si se envan dos datagramas consecutivos
(primero A y segundo B) al mismo destino, cada uno es enrutado de manera independiente
tomando diferentes caminos, pudiendo llegar primero B y luego A(5).
El IP tiene dos funciones principales: direccionamiento y fragmentacin.
El modelo de operacin se basa en un mdulo de Internet en cada host (dispositivos de
usuario final que conectan al usuario a la red, por ejemplo: computadora personal, impresora,
etc.) conectado a Internet y en cada gateway que interconecta redes. Estos mdulos comparten
____________________________________________________________________________

_________________________________________________________________________
reglas en comn para interpretar los campos de direccin y para fragmentar y reacomodar los
datagramas IP. Adems, estos mdulos (especialmente en los gateways) tienen procedimientos
para tomar decisiones de enrutamiento y otras funciones.
Los mdulos de Internet usan las direcciones que se llevan en el encabezado de Internet
para transmitir los datagramas hacia sus destinos. La seleccin del camino para la transmisin
se llama enrutamiento. Tambin, los mdulos de Internet usan los campos en el encabezado de
Internet para fragmentar y reacomodar los datagramas IP cuando es necesario para la
transmisin sobre redes pequeas(6).
El IP usa cuatro mecanismos para proveer estos servicios:
-
Tipo de servicio: es usado para indicar la calidad deseada del servicio. El tipo de servicio
es un grupo generalizado de parmetros que caracterizan las opciones de servicio
disponibles en la red, y las cuales conforman la Internet. La indicacin del tipo de servicio
se usa en los gateways para seleccionar los actuales parmetros de transmisin para una
red particular, la red a ser usada en el prximo salto, o el prximo gateway cuando se
enruta un datagrama IP.
Tiempo de vida: es una indicacin de un lmite en el tiempo de vida de un datagrama IP.

Este es configurado por el que enva el datagrama y es reducido en ciertos puntos del
camino donde es procesado. Si el tiempo de vida llega a cero antes de que el datagrama IP
llegue a su destino, se destruye el datagrama. El tiempo de vida se puede pensar como un
tiempo lmite para la autodestruccin.
Opciones: Proveen las funciones de control necesarias o tiles en algunas situaciones, pero
innecesarias para la mayora de las comunicaciones comunes. Las opciones incluyen las
provisiones para registros de tiempo, seguridad y enrutamientos especiales.
Verificacin de suma del encabezado (en ingls: Header Checksum): provee una
verificacin de la correcta transmisin de la informacin en los datagramas IP durante su
procesamiento. La informacin puede contener errores. Si al verificacin de suma del
encabezado falla, inmediatamente se desecha el datagrama IP por la entidad que detecta el
error.
Para tener una mejor idea de la ubicacin del IP con respecto a otros protocolos, a
continuacin se muestra la figura 1 que ilustra la jerarqua de protocolos(6):
____________________________________________________________________________

_________________________________________________________________________
Figura 1: Relacin de protocolos
Actualmente se usa el la versin 4 de IP o mejor conocida como IPv4, sta se dise antes
de que se produjera una gran demanda de direcciones. El crecimiento explosivo de Internet ha
amenazado con agotar el suministro de direcciones IP. La divisin en subredes, la Traduccin
de Direcciones en Red (sus siglas en ingls NAT, por Network Address Translation) y el
direccionamiento privado se utilizan para extender el direccionamiento IP sin agotar el
suministro. Otra versin de IP conocida como IPv6 (versin nueva y poco implementada)
mejora la versin actual proporcionando un espacio de direccionamiento mucho mayor,
integrando o eliminando los mtodos utilizados para trabajar con los puntos dbiles del IPv4(7).
Con respecto al datagrama IP, se tiene una parte de encabezado y una parte de texto. El
encabezado tiene una parte fija de 20 bytes y una parte opcional de longitud variable. El
formato del encabezado se muestra a continuacin, este se transmite en orden de big endian:
de izquierda a derecha del campo Version(8). A continuacin el formato de encabezado
IPv4(9) en la figura 2:
0
Version
Long.
Encabezado
10
11
12
13
15
16
17
18
Tipo de Servicio
Protocolo
19
20
21
22
23
24
25
26
27
28
29
30
31
Longitud total
Identifi
cadores
Identificacin
Tiempo de vida
14
Posicin de fragmento
Verificacin de suma del encabezado

Direccin IP origen
Direccin IP destino
Opciones
Informacin
Figura 2: Formato encabezado IPv4

Los campos del encabezado de IPv4 se describen a continuacin:
____________________________________________________________________________

10
_________________________________________________________________________
-
Versin (4 bits): Este campo indica la versin IP utilizada. Este caso se describe la versin
4.
Longitud del encabezado IP (4 bits): Longitud del encabezado en palabras de 32 bits. Su

valor mnimo es de 5 para un encabezado correcto.
Tipo de Servicio (8 bits): Indica la calidad de servicio deseada mediante la especificacin

de cmo los protocolos de capas superiores quieren que se manipule el actual datagrama
(se asignan varios niveles de importancia a los datagramas). Este campo se usa para la
asignacin de precedencia, retardo, rendimiento de procesamiento y confiabilidad.
Longitud Total (16 bits): Es el tamao total del datagrama (en octetos), incluyendo el
tamao del encabezado y el de los datos. El tamao mximo de los datagramas usados
normalmente es de 576 octetos (64 de encabezado y 512 de datos). Una mquina no
debera enviar datagramas mayores a no ser que tenga la certeza de que van a ser
aceptados por la mquina destino. En caso de fragmentacin este campo contendr el
tamao del fragmento, no el del datagrama original.
Identificacin (16 bits): Identificador nico del datagrama. Se utilizar, en caso de que el
datagrama deba ser fragmentado, para poder distinguir los fragmentos de un datagrama de
los de otro. El que enva el datagrama, se debe asegurar un valor nico para la pareja
origen-destino y el tipo de protocolo durante el tiempo que el datagrama pueda estar activo
en la red.
Identificadores (3 bits): Consiste en un campo de 3 bits, de los cuales los dos menos
significativos son de control de fragmentacin. El bit menos significativo especifica si el
paquete puede ser fragmentado. El bit medio indica si el paquete es el ltimo fragmento en
una serie de paquetes fragmentados. El tercer bit o el ms significativo no se usa.
Posicin de Fragmento (13 bits): En paquetes fragmentados indica la posicin, en unidades

de 64 bits, que ocupa el paquete actual dentro del datagrama original. El primer paquete de
una serie de fragmentos contendr en este campo el valor 0.
Tiempo de Vida (8 bits): Este campo indica el tiempo mximo en el que el datagrama
puede permanecer en el sistema de Internet. Es un contador que gradualmente va
decreciendo hasta cero, cuando esto sucede se desecha el datagrama. Esto evita que el
datagrama entre en un ciclo infinito.
____________________________________________________________________________

11
_________________________________________________________________________
-
Protocolo (8 bits): Indica el protocolo de capa superior utilizado en la parte de datos del
datagrama
Verificacin de suma del Encabezado (16 bits): Ayuda a mantener la integridad del
encabezado IP. Se recalcula cada vez que algn nodo cambia alguno de sus campos (por
ejemplo, el Tiempo de Vida). El mtodo de clculo (intencionadamente simple) consiste
en sumar el complemento a1 de cada palabra de 16 bits del encabezado y hacer el
complemento a1 del valor resultante
Direccin IP origen (32 bits): Indica el nodo de origen.
Direccin IP destino (32 bits): Indica el nodo de destino.
Opciones (longitud variable de 0 a 32 bits): Permite al IP soportar una serie de opciones,

por ejemplo: seguridad.
Informacin (longitud variable de 0 a 32 bits): Contiene informacin de capas superiores.
2.2.1. DIRECCIONES IP:

Cada host o cada router conectado a una red TCP/IP debe recibir un identificador
exclusivo o una direccin IP. Esta direccin, que opera en la capa 3 del modelo OSI, permite
que un computador localice otro computador en la red. Todos los computadores tambin
cuentan con una direccin fsica exclusiva, conocida como direccin MAC. Estas son
asignadas por el fabricante de la tarjeta de interfaz de la red. Las direcciones MAC operan en
la Capa 2 del modelo OSI.
Una direccin IP es una secuencia de unos y ceros de 32 bits. Para que el uso de la
direccin IP sea ms sencillo, en general, la direccin aparece escrita en forma de cuatro
nmeros decimales separados por puntos. Por ejemplo, la direccin IP de un computador es
192.168.1.2. Otro computador podra tener la direccin 128.10.2.1. Esta forma de escribir una
direccin se conoce como formato decimal punteado. En esta notacin, cada direccin IP se
escribe en cuatro partes separadas por puntos. Cada parte de la direccin se conoce como
octeto porque se compone de ocho dgitos binarios. Por ejemplo, la direccin IP 192.168.1.8
sera 11000000.10101000.00000001.00001000 en una notacin binaria. La notacin decimal
punteada es un mtodo ms sencillo de comprender que el mtodo binario de unos y ceros.
Esta notacin decimal punteada tambin evita que se produzca una gran cantidad de errores
____________________________________________________________________________

12
_________________________________________________________________________
por omisin y/o transposicin (error por factor humano), que s se producira si slo se
utilizaran nmeros binarios. El uso de decimales separados por puntos permite una mejor
comprensin de los patrones numricos(7).
Es importante mencionar que una direccin IP realmente no se refiere a un host, sino a una
interfaz de red, es decir, si un host est en dos redes, debe tener dos direcciones IP. Sin
embargo, en la prctica la mayora de los hosts se encuentran en una red, por lo que slo
tienen una direccin IP.
2.2.2. IPv4:
En el IPv4 cada direccin IP consta de dos partes. Una parte identifica la red donde se
conecta el sistema y la segunda identifica el sistema en particular de esa red. Como se puede
observar en la figura 3, cada octeto vara de 0 a 255. Cada uno de los octetos se divide en 256
subgrupos y stos, a su vez, se dividen en otros 256 subgrupos con 256 direcciones cada uno.
Al referirse a una direccin de grupo inmediatamente arriba de un grupo en la jerarqua, se
puede hacer referencia a todos los grupos que se ramifican a partir de dicha direccin como si
fueran una sola unidad.
Figura 3: Jerarqua de las direcciones IPv4

Este tipo de direccin recibe el nombre de direccin jerrquica porque contiene diferentes
niveles. Una direccin IP combina estos dos identificadores en un solo nmero. Este nmero
debe ser un nmero exclusivo, porque las direcciones repetidas haran imposible el
____________________________________________________________________________

13
_________________________________________________________________________
enrutamiento. La primera parte identifica la direccin de la red del sistema. La segunda parte,
la parte del host, identifica qu mquina en particular de la red(7).
2.2.3. CLASES DE DIRECCIONES IP:
Las direcciones IP se dividen en 5 clases para definir las redes de tamao pequeo,
mediano y grande. Esto se conoce como direccionamiento con clase (en ingls: classful
addressing). Las direcciones Clase A se asignan a las redes de mayor tamao. Las direcciones
Clase B se utilizan para las redes de tamao medio y las de Clase C para redes pequeas. La
clase D se utiliza para grupos de multicast (en espaol: multidifusin) y la clase E se reserva
para fines de investigacin solamente. A continuacin en la tabla 3 se muestran el nmero de
bits asignados a la porcin de red, cantidad de redes, nmero de bits asignados a la porcin de
host y la cantidad de host por red, correspondientes a cada clase(7):
Clase
A
B
C
D (Multicast)
Nmero de bits
Cantidad de
indicadores de
Redes
Red
7
126*
14
16.384
21
2.097.152
No es aplicable
Nmero de bits
Cantidad de host
indicadores de
por red
host
24
16.777.216
16
65.535
8
254
No es aplicable
Tabla 3: Clases de direcciones IP

* El intervalo de direcciones 127.x.x.x est reservado como direccin de loopback, con
propsitos de prueba y de diagnstico.
Es importante denotar que la primera (porcin de host en cero) y ltima direccin (porcin
de host en unos) de las clases A, B y C no se asignan a ningn equipo, ya que la primera
direccin (por ejemplo en clase C: 192.168.0.0) corresponde a la direccin de la red en s y, la
ltima direccin (por ejemplo en clase C: 192.168.255.255) corresponde a la direccin de
broadcast (en espaol: difusin) de la red.
Los formatos de cada clase y los rangos de direcciones se muestran en la figura 4(10):
____________________________________________________________________________

14
_________________________________________________________________________
Figura 4: Formato y rango de direcciones IP segn la clase

Hay ciertas direcciones en cada clase de direccin IP que no estn asignadas y que se
denominan direcciones privadas. Las direcciones privadas pueden ser utilizadas por los hosts
que usan traduccin de direccin de red (NAT) para conectarse a una red pblica o por los
hosts que no se conectan a Internet. En una misma red no pueden existir dos direcciones
iguales, pero s se pueden repetir en dos redes privadas que no tengan conexin entre s o que
se sea a travs de NAT. Las direcciones privadas se muestran en la tabla 4(7):
Clase
A
B
C
Intervalo de direcciones privadas (RFC 1918)

10.0.0.0 a 10.255.255.255
172.16.0.0 a 172.31.255.255
192.168.0.0 a 192.168.255.255
Tabla 4: Direcciones privadas
2.2.4. SUBREDES (EN INGLS: SUBNETTING):
Las clases de direcciones IP ofrecen de 256 a 16,8 millones de hosts. Para administrar de
forma eficiente un nmero limitado de direcciones IP, todas las clases pueden subdividirse en
subredes ms pequeas.
Cuando se trabaja con una red pequea, con pocos host conectados, el administrador de
red puede fcilmente configurar el rango de direcciones IP usado para conseguir un
____________________________________________________________________________

15
_________________________________________________________________________
funcionamiento ptimo del sistema. Pero conforme la red va creciendo se hace necesaria una
divisin en partes de la misma. Existen muchas razones a favor de crear subredes:
-
Reduccin del trfico en la red: Con el uso de routers se crean dominios de broadcast,
con los cuales se reduce el trfico total en la red y slo se restringen a la red local (slo
los paquetes destinados a otras redes pasarn por el router). A mayor nmero de
dominios de broadcast, menor sern los tamaos de los mismos y menor el trfico de
red en cada segmento o dominio de colisin.
Optimizacin del desempeo de la red: Esto se debe a la reduccin del trfico en la

red.
Manejo simplificado: Resulta ms fcil identificar un problema aislado de red en un

grupo de pequeas redes conectadas que dentro una red gigantesca.
Facilidad en atravesar largas distancias geogrficas: Debido a que enlaces WAN son
considerablemente ms lentos y ms caros que los enlaces LAN, un sola gran red que
se extienda largas distancias puede crear numerosos problemas. Sin embargo,
conectando mltiples redes pequeas se hace que el sistema sea mucho ms eficiente.
Para crear la estructura de subred, los bits de host se deben reasignar como bits de subred.
Este proceso es a veces denominado "prestar" bits. El punto de inicio de este proceso se
encuentra siempre en el bit del host del extremo izquierdo, aquel que se encuentra ms cerca
del octeto de red anterior.
Las direcciones de subred incluyen la porcin de red Clase A, Clase B o Clase C adems
de un campo de subred y un campo de host. El campo de subred y el campo de host se crean a
partir de la porcin de host original de la direccin IP entera. Esto se hace mediante la
reasignacin de bits de la parte de host a la parte original de red de la direccin. La capacidad
de dividir la porcin de host original de la direccin en nuevas subredes y campos de host
ofrece flexibilidad de direccionamiento al administrador de la red.
Adems de la necesidad de contar con flexibilidad, la divisin en subredes permite que el
administrador de la red brinde contencin de broadcast y seguridad de bajo nivel en la LAN.
La divisin en subredes ofrece algo de seguridad ya que el acceso a las otras subredes est
disponible solamente a travs de los servicios de un router. Adems, el uso de listas de acceso
____________________________________________________________________________

16
_________________________________________________________________________
puede ofrecer seguridad en el acceso. Estas listas pueden permitir o negar el acceso a la
subred, tomando en cuenta varios criterios, de esta manera brindan mayor seguridad. Para la
implementacin de subredes son necesarias las mscaras de subred(7).
2.2.5. MSCARAS DE SUBRED:
Son aquellas mscaras que indican la divisin entre el nmero de red, el nmero de subred
y el host. Las mscaras de subred son valores de 32 bits, que tambin se pueden escribir en
notacin decimal con puntos, en binario o agregando a la direccin IP un diagonal seguida del
nmero de bits usados para los nmeros de red y subred. Por ejemplo, en una direccin clase
B, puede indicar una mscara de subred de la siguiente manera:
-
255.255.252.0
11111111 11111111 11111100 00000000
172.20.4.1/22
2.2.6. MSCARAS DE SUBRED DE LONGITUD VARIABLE:
Las mscaras de subred de longitud variable o VLSM (Variable Length Subnet Masks) son
aquellas que permiten el uso de ms de una mscara de subred dentro de una misma direccin
de red. Ms especficamente, la implementacin de las VLSM es la divisin de una red en
subredes, a su vez algunas de estas subredes son divididas en sub-subredes y as
sucesivamente hasta que el administrador lo crea conveniente. Este proceso recursivo hace que
el manejo de las direcciones IP asignadas sea ms eficiente, y se reduce la informacin de
enrutamiento en niveles superiores. A continuacin en la figura 5 se aprecia la divisin
recursiva de las subredes:
____________________________________________________________________________

17
_________________________________________________________________________
Figura 5: Divisin recursiva de subredes
Ninguno de los protocolos de enrutamiento RIPv1 (Routing Information Protocol versin

1 o Protocolo de Informacin de Enrutamiento) o IGRP (Interior Gateway Routing Protocol o
Protocolo de Enrutamiento de Gateway Interior) tienen campo para informacin de subredes,
lo que significa que un router que usa RIP y tiene una mscara de subred de cierto valor, ste
asume que todas la interfaces dentro del espacio de direcciones con clase (en ingls: classful)
tienen la misma mscara de subred. Esto se llama enrutamiento con clase (en ingls: classful
routing), y el RIP e IGRP son considerados protocolos de enrutamiento con clase. Si se
mezclan y se hacen coincidir longitudes de mscaras de subred en una red que usa RIP o
IGRP, la red simplemente no funcionar.
Sin embargo, los protocolos de enrutamiento sin clase (en ingls: classless routing
protocols), si soportan la informacin de subredes. Por lo que, las VLSM se pueden usar con
los protocolos RIPv2, IS-IS, EIGRP o OSPF. Como se ha mencionado, el beneficio de este
tipo de redes es el ahorro de gran cantidad de direcciones IP(9).
2.3. PROTOCOLO TCP:

El Protocolo para el control de la transmisin o TCP (RCF 793) es un protocolo de Capa 4
(segn el modelo de referencia OSI) orientado a conexin que suministra una transmisin de
datos full-duplex confiable. TCP forma parte de la pila del protocolo TCP/IP. En un entorno
orientado a conexin, se establece una conexin entre ambos extremos antes de que se pueda
iniciar la transferencia de informacin. TCP es responsable de la divisin de los mensajes en
segmentos, reensamblndolos en la estacin destino, reenviando cualquier mensaje que no se
____________________________________________________________________________

18
_________________________________________________________________________
haya recibido y reensamblando mensajes a partir de los segmentos. TCP suministra un circuito
virtual entre las aplicaciones del usuario final(11). Los protocolos que usan TCP incluyen:
-
FTP (Protocolo de transferencia de archivos)
HTTP (Protocolo de transferencia de hipertexto)
SMTP (Protocolo simple de transferencia de correo)
Telnet
Dado que el TCP es un protocolo orientado a conexin. Este requiere que se establezca
una conexin antes de que comience la transferencia de datos. Para que se establezca o
inicialice una conexin, los dos hosts deben sincronizar sus Nmeros de Secuencia Iniciales
(sus siglas en ingls ISN, por Initial Sequence Numbers). La sincronizacin se lleva a cabo a
travs de un intercambio de segmentos que establecen la conexin al transportar un bit de
control denominado SYN (para la sincronizacin), y los ISN. Los segmentos que transportan
el bit SYN tambin se denominan "SYN". Esta solucin requiere un mecanismo adecuado
para elegir un nmero de secuencia inicial y un proceso levemente complicado para
intercambiar los ISN.
La sincronizacin requiere que ambos lados enven su propio Nmero de Secuencia Inicial
o ISN y recibir la confirmacin del cambio en un Acuse de Recibo o ACK (Acknowledgment)
del otro lado. La secuencia se muestra y se explica a continuacin en la figura 6:
A
Enva SYN (seq = x)
Recibe SYN (seq = x)

Enva SYN (seq = y,
ACK = x + 1)
Recibe SYN (seq = y,

ACK = x + 1)
Enva ACK
(ACK = y + 1)
Enva ACK
(ACK = y + 1)
Figura 6: Intercambio de seales de tres vas

____________________________________________________________________________

19
_________________________________________________________________________
1. El origen (A) inicializa una conexin enviando un paquete de SYN hacia el host destino
(B) indicando su INS = X: A>B SYN, seq de A = X
2. B recibe el paquete, graba que el seq de A = X, responde con un ACK de X + 1, e indica
que su INS = Y. El ACK de X + 1 significa que el host B recibi todos los octetos
incluyendo X y ahora espera X + 1 siguiente: B>A ACK, seq de A = X, SYN seq de B =
Y, ACK = X + 1
3. A recibe el paquete de B, y sabe que el seq de B = Y, y responde con un ACK de Y + 1, el
cual termina el proceso de conexin: A>B ACK, seq de B = Y, ACK = Y + 1
Este intercambio se denomina intercambio de seales de tres vas (en ingls: Three Way
Handshake).
El intercambio de seales de tres vas es necesario dado que los nmeros de secuencia no
estn conectados a ningn reloj global de la red y los protocolos TCP pueden tener distintos
mecanismos para elegir el ISN. El receptor del primer SYN no tiene forma de saber si el
segmento es un antiguo segmento demorado, a menos que recuerde el ltimo nmero de
secuencia utilizado en la conexin. No siempre es posible recordar ese nmero. Por lo tanto,
debe solicitar al emisor que verifique este SYN(7).
El formato del encabezado TCP se muestra en la figura 7(12):
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Puerto Origen
Puerto de destino
Nmero de secuencia
Nmero de acuse de recibo
U A P R S F
Posic. de
Reservado
Ventana
R C S S Y I
los datos
G K H T N N
Suma de control
Puntero urgente
Opciones
Relleno
Datos
Figura 7: Formato encabezado TCP

Los campos del encabezado TCP se describen a continuacin:
-
Puerto origen (16 bits): El nmero del puerto origen.
____________________________________________________________________________

20
_________________________________________________________________________
-
Puerto destino (16 bits): El nmero del puerto de destino.
Nmero de secuencia (32 bits): El nmero que se usa para asegurar el secuenciamiento
correcto de los datos entrantes.
Nmero de acuse de recibo (32 bits): Si el bit de control ACK est puesto a uno, este
campo contiene el valor del siguiente nmero de secuencia que el emisor del
segmento espera recibir.
Posicin de los datos (4 bits): El nmero de palabras de 32 bits que ocupa el

encabezado TCP. Este nmero indica dnde comienzan los datos.
Reservado (6 bits): Reservado para uso futuro. Debe valer 0.
Bits de control (6 bits): URG:

ACK:
Hace significativo el campo "Puntero urgente";
Hace significativo el campo "Nmero de acuse de recibo"; PSH:
Funcin de "Entregar datos inmediatamente" ('push'); RST: Reiniciar ('Reset')

la conexin; SYN: Sincronizar ('Synchronize') los nmeros de secuencia; FIN:
ltimos datos del emisor
-
Ventana (16 bits): La cantidad de octetos que el emisor est dispuesto a aceptar.
Suma de Control (16 bits): Suma de comprobacin calculada a partir de los campos del
encabezado y de los datos.
Puntero urgente (16 bits): Este campo indica el valor actual del puntero urgente como
un desplazamiento positivo desde el nmero de secuencia de este segmento. El
puntero urgente apunta al nmero de secuencia del octeto al que seguirn los
datos urgentes. Este campo es interpretado nicamente si el bit de control URG
est establecido a uno.
Opcin (longitud variable de 0 a 24 bits): Los campos de opciones pueden ocupar un

cierto espacio al final de la cabecera de TCP, pero siempre de una longitud
mltiplo de 8 bits. En el clculo de la suma de control, se incluyen todas las
opciones. Una opcin puede empezar en cualquier posicin mltiplo de ocho.
Relleno (longitud variable de 0 a 8 bits): El relleno de la cabecera de TCP se utiliza

para asegurar que la cabecera de TCP finaliza, y que los datos comienzan, en
una posicin mltiplo de 32 bits. El relleno est compuesto de ceros.
Datos (longitud variable de 0 a 32 bits): Datos de protocolo de capa superior.
____________________________________________________________________________

21
_________________________________________________________________________
2.4. PROTOCOLO UDP:
El Protocolo de datagrama de usuario o UDP (User Datagram Protocol) es el protocolo de

transporte no orientado a conexin de la pila de protocolo TCP/IP. El UDP (RFC 768) es un
protocolo simple que intercambia datagramas sin que se haya establecido previamente una
conexin, ya que el propio datagrama incorpora suficiente informacin de direccionamiento en
su encabezado. No posee confirmacin, ni control de flujo, por lo que los paquetes pueden
adelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya que no hay
confirmacin de entrega o de recepcin. El procesamiento de errores y la retransmisin deben
ser manejados por protocolos de capa superior.
Dado que el UDP no usa ventanas ni acuses de recibo, la confiabilidad, en caso de ser
necesaria, se suministra a travs de protocolos de la capa de aplicacin. El UDP est diseado
para aplicaciones que no necesitan ensamblar secuencias de segmentos. Los protocolos que
usan UDP incluyen(7):
-
TFTP (Protocolo trivial de transferencia de archivos)
SNMP (Protocolo simple de administracin de red)
DHCP (Protocolo de configuracin dinmica del host)
DNS (Sistema de denominacin de dominios)
El formato del encabezado UDP se muestra en la figura 8(13):

0
10
11
12
13
14
15
16
17
18
19
20
Puerto de origen
Longitud
21
22
23
24
25
26
27
28
29
30
31
Puerto de destino
Suma de control
Octeto de datos
Figura 8: Formato encabezado UDP

Los campos del encabezado UDP se describen a continuacin:
-
Puerto origen (opcional): indica el puerto del proceso emisor, y puede que se asuma
que se sea el puerto al cual la respuesta debera ser dirigida en ausencia de otra
informacin. Si no se utiliza, se inserta un valor cero.
____________________________________________________________________________

22
_________________________________________________________________________
-
Puerto destino: tiene significado dentro del contexto de una direccin de destino en un
entorno internet particular.
Longitud: Nmero de bytes que se incluyen en el encabezado y los datos (el valor
mnimo de este campo es 8).
Checksum (suma de comprobacin): Suma de comprobacin calculada a partir de los

campos del encabezado y de los datos.
Datos: Datos de protocolo de capa superior.
2.5. NMEROS DE PUERTOS TCP Y UDP:

Tanto TCP como UDP utilizan nmeros de puerto para enviar informacin a las capas
superiores. Los nmeros de puerto se utilizan para mantener un registro de las distintas
conversaciones que atraviesan la red al mismo tiempo.
Los programadores de software de aplicacin han aceptado usar los nmeros de puerto
conocidos (en ingls: well known ports) que emite la Agencia de Asignacin de Nmeros de
Internet (sus siglas en ingls: IANA, por Internet Assigned Numbers Authority). Cualquier
conversacin dirigida a la aplicacin FTP usa los nmeros de puerto estndar 20 y 21. El
puerto 20 se usa para la parte de datos y el puerto 21 se usa para control. A las conversaciones
que no involucran ninguna aplicacin que tenga un nmero de puerto bien conocido, se les
asignan nmeros de puerto que se seleccionan de forma aleatoria dentro de un rango
especfico por encima de 1023. Algunos puertos son reservados, tanto en TCP como en UDP,
aunque es posible que algunas aplicaciones no estn diseadas para admitirlos. Los nmeros
de puerto tienen los siguientes rangos asignados:
-
Los nmeros inferiores a 1024 corresponden a nmeros de puerto bien conocidos.
Los nmeros superiores a 1023 son nmeros de puerto asignados de forma dinmica.
Los nmeros de puerto registrados son aquellos nmeros que estn registrados para
aplicaciones especficas de proveedores. La mayora de estos nmeros son superiores a
1024.
____________________________________________________________________________

23
_________________________________________________________________________
Los sistemas finales utilizan nmeros de puerto para seleccionar la aplicacin adecuada. El
host origen asigna de forma dinmica los nmeros del puerto de origen. Estos nmeros son
siempre superiores a 1023(7).
Algunos protocolos claves y puertos que usan TCP y UDP se muestran en la tabla 5(14):
Uso de
TCP
Uso de
UDP
Protocolos
Telnet
SMTP
HTTP
FTP
HTTPS
Puerto
23
25
80
21
443
DNS
53
TFTP
RIP
POP3
SNMP
69
520
110
161
Tabla 5: Puertos que usan TCP y UDP
2.6. ESTNDAR DE VIDEOCONFERENCIA H.323:

H.323 es un estndar bajo el amparo de la ITU (International Telecommunications Union)
desde el ao 1996 y se ha estado actualizando regularmente (la versin ms reciente es el
H.323 versin 6 de fecha junio de 2006(15)), y engloba un conjunto de estndares que proveen
especificaciones para terminales, equipos de redes y servicios en la comunicacin multimedia
sobre redes que no proporcionan calidad de servicio o QoS (sin embargo, desarrollos recientes
en la tecnologa de redes IP han introducido mecanismos de QoS que han permitido mejoras
en la calidad de voz/video). Estas redes son las que predominan hoy en todos los lugares,
como redes de paquetes conmutadas TCP/IP e IP sobre Ethernet, Fast Ethernet, Giga Ethernet,
FDDI y Token Ring. Por esto, los estndares H.323 son bloques importantes de construccin
para un amplio rango de aplicaciones basadas en redes de paquetes para la comunicacin
multimedia y el trabajo en conjunto, esto permite establecer videoconferencia sobre redes de
rea local o LAN, redes de rea amplia o WAN y redes de rea metropolitana o MAN
(Metropolitan Area Networks).
____________________________________________________________________________

24
_________________________________________________________________________
El H.323 es el principal estndar en el rea de Voz sobre IP (VoIP). El trmino de VoIP no
abarca solo la transmisin de voz sobre redes IP, sino una cantidad de aplicaciones que ahora
se estn integrando de manera satisfactoria gracias a la universalidad de las redes IP. Mejoras
en el desempeo de las redes Ethernet e IP, como tambin los avances en el manejo del ancho
de banda, permiten que aplicaciones tradicionales de redes conmutadas como la distribucin
automtica de llamadas, mensajes en tiempo real y trabajo a distancia sean ofrecidas en las
redes IP. Como se ha mencionado, en adicin a las aplicaciones de voz, el H.323 en
combinacin con el estndar ITU-T T.120 provee mecanismos para la videocomunicacin y
colaboracin de informacin. El estndar H.323 es tambin llamado Paragua de estndares,
ya que este refiere a su vez a muchos estndares, como se observ en la tabla 2.
Brevemente, los componentes de una red H.323 son: Terminal (equipo de
videoconferencia que permite comunicacin bidireccional en tiempo real), Gatekeeper
(Administrador de llamadas: registro de equipos, responsable de traducir los alias a
direcciones IP, administracin del ancho de banda), Gateway (permite la comunicacin entre
el mundo H.323 y equipos de videoconferencia que trabajan H.320, ya sea ISDN o V.35) y
MCU (Multipoint Conference Unit, el cual permite la comunicacin entre mltiples sitios).
La comunicacin de estos cuatro componentes se realiza mediante el intercambio de
informacin, la cual se divide en cinco categoras:
-
Audio/voz (digitalizada y codificada).
Video (la comunicacin de imgenes de movimiento completo es digitalizada y

codificada).
Datos (archivos como documentos de texto o imgenes).
Comunicacin de control (intercambio de funciones, control de canales lgicos, etc.).
Conexiones de control (configuracin de la conexin y liberacin de la conexin, etc.).
El flujo de informacin es enrutada de acuerdo al estndar H.225 hacia la interfaz LAN,

esto se basa en la capa de transporte (capa 4) segn el modelo de referencia ISO/OSI. La
interfaz LAN no depende del H.323 sino de la red usada. El indispensableque exista la
transmisin confiable como la no confiable, las cuales son manejadas en la redes IP por el
TCP y el UDP, respectivamente. Posterior a la capa H.225, la interfaz consiste en codecs de
audio y video, respectivos a los estndares H.225 y H.245. El terminal y la interfaz con el
____________________________________________________________________________

25
_________________________________________________________________________
usuario no corresponden al H.323(16). A continuacin la figura 9, en la que se muestra la
arquitectura general del H.323(17):
Aplicacin
de usuarios
(T.120, etc)
Interfaz de usuario
Sistema de Control
RAS
Control
H.225
Control
llamada
H.225
Q.931
UDP
Control
H.245
Equipos
de Audio
I/O
Codec
Audio
G.711,
G.722,
G.722.1,
G.723,
G.723.1
G.728,
G.729
Equipos
de Video
I/O
Codec
Video
H.261,
H.263,
H.264
Capa H.225
TCP
UDP
RTP/RTCP
IP
Figura 9: Arquitectura general de H.323

Los componentes de una estructura H.323 se definen a continuacin (18):
-
Terminal: Estos representan los puntos terminales de cada conexin H.323 y se puede
realizar en hardware o software. Son usados para la comunicacin multimedia
bidireccional en tiempo real, un terminal H.323 puede ser una computadora personal o un
equipo independiente (en ingls: stand alone). Estos soportan la comunicacin de audio y
pueden de manera opcional, soportar comunicacin de video y/o datos, debido a que el
servicio principal que proveen los terminales H.323 es la comunicacin de audio. La meta
principal del H.323 es interconectar distintos terminales multimedias. Existe la
compatibilidad con terminales H.324 sobre SCN (las redes SCN incluyen todas las redes
de telefona conmutada, por ejemplo: la red pblica de telefona conmutada o PSTN) y
____________________________________________________________________________

26
_________________________________________________________________________
redes inalmbricas, terminales H.310 y H.321 sobre ISDN-B, terminales H.320 sobre
ISDN y terminales H.322 sobre redes donde se garantice la calidad de servicio o QoS en
LAN. Los terminales H.323 se pueden usar en conferencias multipuntos. A continuacin
en la figura 10, se muestran dos terminales en una zona H.323:
IP
H.323
Terminal H .323
Terminal H .323
Figura 10: Terminales H.323
Gateway: Su funcin es conectar dos redes diferentes, es decir, provee la conexin entre
redes H.323 y otros tipos de redes. Por ejemplo: un gateway puede conectar y proveer
comunicacin entre un terminal H.323 y una red SCN. Esta conexin de distintas redes se
realiza mediante la traduccin de protocolos de configuracin y liberacin de llamadas,
conversin de formatos de los medios y la transferencia de informacin de las redes
conectadas al gateway. Para la comunicacin entre dos terminales en una red H.323, el uso
de un gateway no es necesaria. A continuacin en la figura 11, se muestra una red en la
que usa un gateway(19):
ISDN
Gateway
Terminal
H.320
PSTN
Terminales
H.323
Internet
Telfono
convencional
Figura 11: Red con Gateway
____________________________________________________________________________

27
_________________________________________________________________________
-
Gatekeeper: Es el que toma el control y manejo de las funciones dentro de una red H.323,
y es tambin un componente opcional. Si existe un gatekeeper, sus servicios tienen que ser
usados por los terminales. Por cada zona H.323 slo se permite un gatekeeper. Las dos
tareas principales de este dispositivo son la conversin de direcciones y administrar el
ancho de banda (tambin realiza el registro de equipos); la conversin de las direcciones
sirve para controlar las conexiones y la administracin del ancho de banda est diseado
para evitar saturaciones. Ambas funciones se realizan mediante el protocolo RAS
(Registration, Admisin and Status) definido en el H.225. El administrador de red es capaz
de asignar una porcin del ancho de banda total para las conexiones H.323 y liberar el
resto para las dems aplicaciones. Si se alcanza el lmite preestablecido, el gatekeeper
rechaza las peticiones de conexin de los terminales o el aumento del ancho de banda para
las conexiones existentes, previniendo la saturacin de la red.
Como el gatekeeper controla el acceso de los terminales mediante el RAS, tambin puede
rechazar conexiones de terminales individuales que no estn autorizados.
Adems, el gatekeeper tambin puede recibir y enrutar los canales H.245 en conexiones
entre dos usuarios. Si la conferencia se extiende a tres o ms usuarios el gatekeeper enruta
el control de los canales H.245 a una unidad de control multipunto o MCU (Multipoint
Control Unit), el cual toma el control sobre la conferencia.

-
Unidades de Control Multipunto o MCU (Multipoint Control Units): son usadas en

conferencias con ms de dos usuarios. Estas aseguran que las conexiones se configuran y
liberan de manera correcta, que el audio y el video estn mezclados, y que los datos o
informacin se distribuyen en la conferencia. Cada terminal H.323 enva su informacin al
MCU. Un MCU consiste en un Controlador Multipunto o MC y una serie de Procesadores
Multipuntos o MP. El controlador multipunto cuida del H.245 y la negociacin general del
procesamiento de las funciones de audio y de video, y controla las fuentes determinando
cul flujo de informacin va a ser transmitido por el/los MP. Los procesadores multipunto
reciben las rfagas de media de los participantes en la conferencia, los procesan y luego lo
distribuyen a los otros terminales.
El procesamiento de video se refiere a todos los algoritmos y formatos, el procesamiento
de audio slo al algoritmo, el procesamiento de datos slo al flujo. En el procesamiento de
video por el MP, se requiere la conmutacin y el mezclado. La conmutacin asegura que
____________________________________________________________________________

28
_________________________________________________________________________
ciertos flujos de datos son enviados si existen gran cantidad de los mismos. El mezclado
permite que varios flujos de datos sean combinados, donde la imagen creada es dividida en
varios segmentos y recodificada.
Los MP tambin realizan la conmutacin y mezcla de audio. Las seales entrantes son
decodificadas en procedimientos estndares segn la Modulacin por Codificacin de
Pulsos o PCM (Pulse Code Modulation), combinadas de manera apropiada y luego
codificadas en el formato de audio deseado. En esta combinacin las seales de
interferencia y el ruido pueden ser disminuidos.
A continuacin en la figura 12 se muestra el uso del MCU(19):
MCU
Multicast de audio y video

Descentralizado
Unicast de audio y video

Centralizado
Figura 12: Uso del MCU

En la figura 13 se muestra la arquitectura de una red H.323 y sus componentes(20):
Figura 13: Arquitectura red H.323 y sus componentes

____________________________________________________________________________

29
_________________________________________________________________________
2.6.1. ESTNDAR DE SEALIZACIN H.225:

El H.225 es un estndar ITU para cubrir la banda estrecha de los servicios de telefona
visual (sistemas de audio y video), definidos en la Recomendaciones H.200/AV.120-Series.
Este estndar se relaciona con aquellas situaciones en las que el trayecto de transmisin
incluye una o ms redes basadas en paquetes, y cada una de stas est configurada y manejada
para no garantizar la calidad de servicio (QoS). El H.225 describe cmo la informacin de
audio, video, data y control (AVDC) puede ser manejada en una red basada en paquetes (IP)
para proveer servicios de conversacin en equipos H.323. El H.225 se divide en dos partes:
Sealizacin de llamada (en ingls: Call Signaling) y el RAS (Registration, Admission and
Status)(21).
Sealizacin de llamada (Call Signaling)(22): es usada para establecer los parmetros de

comunicacin entre puntos terminales (en ingls: endpoints) H.323, sobre los cuales puede
ser transportada informacin en tiempo real. Esto es posible mediante el intercambio de
mensajes de protocolo H.225 en el canal call-signalling. Este canal es abierto entre puntos
terminales H.323 o entre un punto terminal y el gatekeeper. La recomendacin ITU H.225
especifica el uso y soporte de mensajes de sealizacin Q.931, stos son codificados segn
el PER (Packed Encoding Rules) del ASN.1(23).
Un canal confiable (TCP) de control de llamada es creado a travs de una red IP por el
puerto TCP nmero 1720. Este puerto inicia los mensajes de control de llamada Q.931
para lograr la conexin, mantener y desconectar llamadas. Cuando un gatekeeper est
presente en la zona de red, una serie de mensajes de configuracin H.225.0 son
intercambiados por Llamada Directa de Sealizacin (Direct Call Signalling) o Llamada
de Sealizacin Enrutada por el gatekeeper (Gatekeeper-Routed Call Signaling - GKRCS).
El gatekeeper decide el mtodo usado durante el intercambio de mensaje de admisin
RAS. Si no hay un gatekeeper, los mensajes H.225 son intercambiados directamente entre
los puntos terminales.
Llamada Directa de Sealizacin(18): Durante la confirmacin de admisin, el

gatekeeper indica que los puntos terminales pueden directamente intercambiar
mensajes de sealizacin de llamada. Los puntos terminales intercambian la
____________________________________________________________________________

30
_________________________________________________________________________
sealizacin de llamada sobre el canal call-signaling, como se ilustra en la figura
14(24):
R
25
H.2
AS
H.2
25
R
H.225/H.245
Sealizacin de
llamada
AS
Portadora de trfico
RTP de voz
Figura 14: Llamada directa de sealizacin
Llamada de Sealizacin Enrutada por el gatekeeper: Los mensajes de admisin son

intercambiados entre puntos terminales y el gatekeeper sobre los canales RAS. EL
gatekeeper recibe los mensajes de sealizacin de llamada sobre el canal callsignaling desde un punto terminal y los enruta hacia el otro sobre el canal callsignaling del punto terminal destino, como se ilustra en la figura 15:
AS
5R
2
2
H.
H.2
H.225/H.245
Sealizacin de
llamada
25
R
AS
Portadora de trfico
RTP de voz
Figura 15: Llamada de sealizacin enrutada por gatekeeper
RAS: es el protocolo entre puntos terminales (terminales y gateways) y gatekeepers. El

RAS es usado para realizar el descubrimiento del gatekeeper, registro de puntos
terminales, ubicacin de puntos terminales, control de admisin y acceso de tokens. Los
mensajes RAS son llevados sobre un canal RAS que no es confiable, por lo que el
intercambio de mensajes RAS puede ser asociado con timeouts y retry counts. Este canal
de sealizacin es abierto entre los puntos terminales y el gatekeeper antes del
establecimiento de cualquier otro canal.
____________________________________________________________________________

31
_________________________________________________________________________
Descubrimiento del gatekeeper (gatekeeper discovery GRQ): este proceso es usado

por los puntos terminales para determinar el gatekeeper con el cual el punto terminal
se debe registrar. El descubrimiento del gatekeeper se puede hacer esttica o
dinmicamente. En el descubrimiento esttico el punto terminal sabe a priori la
direccin de transporte de su gatekeeper. En el descubrimiento dinmico, el punto
terminal enva mltiples mensajes GRQ sobre la direccin multicasts de los
gatekeepers, es decir, el punto terminal pregunta quin es mi gatekeeper?, y uno o

varios gatekeeper puede responder con un mensaje GCF: yo puedo ser tu gatekeeper.
Registro de puntos terminales (endpoint registration): es un proceso usado por los

puntos terminales para unirse a una zona e informarle al gatekeeper de la zona de
transporte y la direccin alias. Todos los puntos terminales se registran al gatekeeper
como parte de su configuracin.
Ubicacin de puntos terminales (endpoint location): es un proceso mediante el cual

la direccin de transporte de un punto terminal es determinada y dada su alias o
direccin E.164.
Otras funciones: El canal RAS es utilizado para otros tipos de mecanismos de

control, como el control de admisin, para restringir la entrada de cualquier otro
punto terminal a la zona, control del ancho de banda y control de desenganche,
donde un punto terminal es desasociado de un gatekeeper y su zona(18).
La estructura del H.225 sigue el estndar Q.931 como se muestra en la figura 16(21):
8bit
5
4
3
2
1
Protocol Discriminator
0
0
Length of call reference bits
Call reference value
Message type
Information Elements
Octet
1
2
3
Figura 16: Estructura del estndar Q.931

Los campos de la estructura del H.225 se describen a continuacin:
Protocol Discriminator: Distingue los mensajes para el control de llamadas de usuarios de

la red de cualquier otro mensaje
Length of call reference bits: Indica la longitud del valor de referencia de la llamada.
____________________________________________________________________________

32
_________________________________________________________________________
Call reference value: Indentifica la peticin de registro/cancelacin de una llamada o una

institucin a la interfaz local de usuarios de red, a la cual el mensaje particular aplica.
Puede ser de hasta 2 octetos de longitud.
Message type: Identifica la funcin del mensaje enviado.
Information Elements (IE): Hay dos categoras de elementos de informacin definidos:

elementos de informacin de un solo octeto y elementos de informacin de longitud
variable, como se muestran en las Figuras 17, 18 y 19:
8
1
6
5
IE Identifier
3
2
Contents of IE
Octet
1

8
1
4
3
IE Identifier
Octet
1

8
1
4
3
IE Identifier
Length of contents of IE
Contents of IE
Octet
1
2
3-n
Figura 19: Formato de elemento de informacin de longitud variable
____________________________________________________________________________

33
_________________________________________________________________________
Algunos mensajes claves del RAS se indican en la tabla 6(22):
Mensaje
Funcin
Solicitud de un terminal o un gatewa' para registrarse
Registration Request
con el gatekeeper. El gatekeeper puede confirmar o
(RRQ)
rechazar la solicitud (RCF o RRJ)
Solicitud de un terminal a un gatekeeper para acceder a
Admisin Request
una red basada en paquetes (IP). El gatekeeper puede
(ARQ)
confirmar o rechazar la solicitud (ACF o ARJ).
Solicitud de un terminal a un gatekeeper para
Bandwidth Request
ubicaciones en las que el ancho de banda es distinto. El
(BRQ)
gatekeeper puede confirmar o rechazar la solicitud
(BCF o BRJ)
Si se enva desde un punto terminal a un gatekeeper, el
DRQ le informa al gatekeeper que el punto terminal
est siendo desconectado; si se enva desde un
Disengage Request
gatekeeper a un punto terminal, el DRQ forza a que se
(DRQ)
desconecte la llamada. El gatekeeper puede confirmar o
rechazar (DCF o DRJ). Si el DRQ es enviado por el
gatekeeper el punto terminal debe responder con el
mensaje de confirmacin DCF.
Solicitud del gatekeeper a un punto terminal sobre
Info Request (IRQ)
informacin de estado.
Respuesta al mensaje de IRQ. Puede ser enviado por el
Info Request Response
terminal al gatekeeper en intervalos predeterminados,
(IRR)
sin ser solicitado por este ltimo.
Valores recomendados por defecto de timeout para la
RAS timers and Request
respuesta de los mensajes RAS y subsecuentes cuentas
in Progress (RIP)
de recomprobacin si la respuesta no es recibida.
Tabla 6: Mensajes RAS
2.6.2. ESTNDAR DE CONTROL H.245:
El H.245 es un estndar o protocolo ITU de control de sealizacin en la arquitectura

multimedia de comunicacin H.323, este protocolo es usado para el intercambio de mensajes
de control H.245 final a final (end-to-end) entre puntos terminales H.323. Los mensajes de
control H.245 son llevados sobre canales de control H.245, este es el canal lgico 0 y est
permanentemente abierto, a diferencia de los medios de comunicacin (en ingls: media
channels). Los mensajes llevados incluyen informacin de capacidad de intercambio entre

____________________________________________________________________________

34
_________________________________________________________________________
terminales, sealizacin de canales lgicos, mensajes de control de flujo, as como comandos e
indicaciones generales(25).
Luego de que una conexin ha sido establecida a travs del procedimiento de sealizacin
de llamada, el protocolo de control de llamadas H.245 es usado para determinar el tipo de
medios de la llamada y establecer el flujo de media, antes de que la llamada pueda ser
establecida. Los mensajes involucrados son los siguientes(26):
Master-to-sub-master determination process: es usado para determinar el terminal

principal de una llamada y es til para evitar conflictos durante las operaciones de control
de llamada.
Capability Exchange procedure: Cada punto terminal le notifica al otro qu tipo de

informacin es capaz de recibir y transmitir a travs de las capacidades de transmisin y
recepcin.
Logical channel procedures: Es usado para abrir y cerrar canales lgicos, que son caminos
multiplexados entre los puntos terminales usados para la transferencia de informacin. Los
canales lgicos son unidireccionales.
Request mode command: Con el uso de este comando en cualquier momento de la

conferencia, el punto terminal receptor puede solicitar un cambio en el modo que se
transmite la informacin, este modo se encuentra en las capacidades de transmisin del
trasmisor y generalmente son: Modo de video, modo de audio, modo de informacin y
modo encriptado.
Control flow command: Este puede ser usado por el receptor para el ajuste del lmite
superior de la tasa de transferencia de bit en cualquier canal lgico.
Communication mode messages: Usado por el controlador multipunto para seleccionar un

modo comn de operacin en una conferencia multipunto.
Conference request and response messages: Usado para controlar conferencias multipunto,
por ejemplo: solicitud de contraseas, control centralizado de conferencia.
Round trip delay commands: Usado para medir el retraso del round-trip entre dos puntos
terminales en el canal de control.
Video fase update command: Usado para solicitar actualizaciones de cuadros de video, en
el caso de prdida de informacin.
____________________________________________________________________________

35
_________________________________________________________________________
End session command: Luego de ejecutar este comando los puntos terminales cierran todos
los canales lgicos, desconectan la llamada y le informan al gatekeeper sobre la
finalizacin de la llamada.
La estructura de los mensajes H.245 siguen la sintaxis ANS.1. Los tipos de Mensaje de
Control de Sistemas Multimedia pueden ser definidos como: solicitud, respuesta, comando y
mensajes de indicacin (en ingls: request, response, command and indication messages).
Alguno de los mensajes claves del H.245 se indican en la tabla 7:
Mensaje
Funcin
Determina cul de los terminales es el principal o
Master-Slave
master y cul es el esclavo. Posibles respuestas:
Determination
Reconocimiento, Rechazo, Liberacin (en caso
de timeout).
Contiene informacin sobre la capacidad los
Terminal Capability terminales de trasmitir y recibir rfagas
Set
multimedias.
Posibles
respuestas:
Reconocimiento, Rechazo, Liberacin.
Abre un canal lgico para el transporte de
Open Logical
informacin audiovisual y de datos. Posibles
Channel
respuestas:
Reconocimiento,
Rechazo,
Confirmacin.
Close Logical
Cierra el canal lgico entre dos puntos
Channel
terminales. Posibles respuestas: Reconocimiento.
Usado por el terminal receptor para solicitar
modos de transmisin particulares al terminal
Request Mode
transmisor. Posibles respuestas: Reconocimiento,
Rechazo, Liberacin.
Le ordena al terminal receptor que indique sus
Send Terminal
capacidades de trasmisin y recepcin con el
Capability Set
envio de uno o varios Grupos de Capacidades del
Terminal (Terminal Capability Sets).
Indica el final de una sesin H.245. Luego
End Session
ejecutar este comando, el terminal no enviar
Command
ningn otro mensaje H.245.
Tabla 7: Mensajes H.245
____________________________________________________________________________
Captulo 3: Videoconferencia sobre IP

_________________________________________________________________________
CAPTULO 3: VIDEOCONFERENCIA SOBRE IP
3.1. DISEO DE UNA RED DE VIDEOCONFERENCIA SOBRE IP:
Teniendo en cuenta lo que es la videoconferencia, sus aplicaciones, los modos de

establecerla (para efectos de este informe se va a desarrollar slo su establecimiento sobre IP)
y todo lo referente a protocolos y estndares que se usan, se puede empezar a disear un
sistema de videoconferencia. Sin embargo, para que este diseo sea eficiente es necesario
formular las siguientes preguntas(27):
Quin va a hacer uso del sistema y para qu?

Esto determina la mayora de las consideraciones tcnicas, la calidad de audio y video que
se debe proveer (QoS), la flexibilidad de la red (uso de gateways o no) y si es necesario las
herramientas para compartir documentos y aplicaciones. En el caso que se quiera compartir
datos o hacer presentaciones al mismo tiempo de que se comparte audio y video de los
participantes, es necesario el uso de equipos de red como routers y switchs para manejar el
intercambio de paquetes (en este caso se usa el estndar ITU H.239 descrito en el Anexo 1)
Qu demanda se espera en el corto, mediano y largo plazo?

Hay que pensar sobre la creciente demanda que se pueda tener del servicio y si el sistema
lo podr soportar. Por ejemplo: La incorporacin de este sistema a una empresa puede
incrementar la eficiencia de la misma y por tanto la necesidad de este servicio puede crecer de
igual manera, haciendo que la capacidad del sistema sea insuficiente. De igual manera, es
importante definir si se quiere un sistema escalable, para en un futuro mejorar o actualizar los
equipos a las nuevas tecnologas lo cual reducira gastos, o si por el contrario no se quiere un
sistema escalable, se podran reducir los costos de adquisicin de los equipos.
Cules son las opciones de arquitectura del sistema y costos?

Es necesario evaluar todas las alternativas para el desarrollo a gran escala del sistema de
videoconferencia y tener un costo estimado. En este punto se tiene que especificar la

____________________________________________________________________________

37
_________________________________________________________________________
tecnologa de enlace (clear channel, frame relay, satelital, etc.), el medio de transmisin
(ISDN, IP o enlace dedicado), el tiempo de respuesta garantizado y el ancho de banda
disponible para poder establecer parmetros de calidad de servicio.
En un sistema de videoconferencia H.323 se recomienda que la capacidad mnima del
canal sea de 384kbps(28). Adems, que el tiempo de respuesta de los enlaces end-to-end no sea
mayor a 500ms (recomendacin obtenida de Tandberg).
Para cuntos usuarios o estaciones se tiene estimado implementar la videoconferencia?

Esto determina el tipo y la cantidad de equipos con los que se debe contar para establecer
una llamada de videoconferencia (uso de MCU para videoconferencias multipunto, tipo de

terminal o codec, tipo y cantidad de micrfonos y cmaras, etc.).
Se posee personal calificado para prestar soporte a esta tecnologa?

La estrategia de implementacin debe contemplar el mantenimiento de los equipos,
actualizacin de los sistemas y soporte en caso de suceder alguna falla. Por lo tanto hay que
capacitar al personal para que realice las configuraciones y puedan operar el sistema de forma
independiente; en el caso de que la capacitacin no sea posible, se deben contratar los
servicios de una empresa calificada para tal fin.
Estas y otras preguntas que puedan surgir segn el caso, van a ayudar e influir
directamente en el diseo de la red de videoconferencia, su implementacin y entrenamiento
de los usuarios y personal tcnico. A manera de ejemplo, se presentan a continuacin dos
escenarios(29):
1.) En la figura 20 se muestran cinco equipos terminales H.323 conectados directamente a

Internet sin ningn dispositivo intermedio, por lo que en este caso slo es posible las
transmisiones punto a punto, es decir, se pueden realizar videoconferencias pero slo entre dos
localidades. (Si se quiere interaccin completa de todos los participantes es necesario el uso de
un MCU).
____________________________________________________________________________

38
_________________________________________________________________________
Caracas
Terminal H.323
Valencia
Maracaibo
Internet
Terminal H.323
Terminal H.323
San Felipe
Mrida
Terminal H.323
Terminal H.323
Figura 20: Escenario 1 (ambiente H.323)
2.) En este segundo escenario se observan tres equipos terminales H.323 que pueden
interactuar entre ellos mismos con el uso de un Servidor de Conferencias Multimedia (en
ingls: Multimedia Conference Server). Pero al momento de intercambiar informacin con una
red ISDN, es necesaria la presencia de un Gateway para traducir de H.323 a H.320 y
viceversa. Ver figura 21:
Terminal H.323
Terminal H.323
ISDN
Network
Gateway
H.323 H.320
H.323 Multimedia
Conference Server
Terminal H.323
Figura 21: Escenario 2 (Ambiente H.323-H-320)
____________________________________________________________________________

39
_________________________________________________________________________
3.2. DISEO E IMPLANTACIN DEL SISTEMA DE VIDEOCONFERENCIA

SOBRE IP AL CNTI:
Para desplegar la red de videoconferencia a nivel nacional, se seleccionaron 2 nodos
principales (1 nodo principal y 1 nodo espejo) y 30 nodos remotos(30):
El nodo principal est ubicado en la oficina del Centro Nacional de Tecnologas de

Informacin (CNTI), Av. Universidad, Esq. El Chorro, y el nodo espejo que posee las
mismas caractersticas que el nodo principal est ubicado en el Palacio de Miraflores, Av.
Urdaneta.
Los 30 nodos remotos estn dispuestos en topologa estrella y con punto central el nodo
principal (oficina del CNTI). Estos nodos estn situados en los mismos lugares donde
funcionan las oficinas estadales de la Fundacin para el Desarrollo de la Ciencia y la
Tecnologa (FUNDACITE) o en las oficinas estadales del Instituto Nacional de
Investigaciones Agropecuarias (INIA). En algunos casos se instalaron nodos en las
comisionadurias de FUNDACITE y existen varios nodos en lugares estratgicos para el
desarrollo del sector. A continuacin en la figura 22, un esquema general del sistema de
videoconferencia:
NODOS
PRINCIPALES
MIRAFLORES
CNTI
NODOS
REMOTOS
1
30
Figura 22: Esquema general del sistema de videoconferencia

Se incluirn 3 unidades mviles (camiones) con sistemas de videoconferencia, con el
propsito de establecer comunicacin con comunidades aisladas que no tienen conexiones a
____________________________________________________________________________

40
_________________________________________________________________________
redes de datos y/o a redes elctricas. Se requieren que dichas unidades funcionen con sistemas
satelitales.
Tambin se incluyen 3 equipos porttiles con sistemas de videoconferencia que permitan
el acceso en cualquier lugar con conexin a Internet.
Las 32 localidades destinadas para las salas de videoconferencia se detallan en la tabla 8:
Sala
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Ubicacin
CNTI, Esq. El Chorro, Caracas.
MIRAFLORES, Esq. Miraflores, Caracas.
FUNDACITE, Maracaibo, Edo. Zulia.
FUNDACITE, Cuman, Edo. Sucre.
INIA, Maracay, Edo. Aragua.
INIA, Mrida, Edo. Mrida.
INIA, Barinas, Edo. Barinas.
CENIT, La Carlota, Caracas.
FUNDACITE Puerto La Cruz, Edo. Anzotegui.
FUNDACITE Regin Guayana, Edo. Bolvar.
NODO La Esmeralda, Edo. Bolvar.(AMAZONAS)
NODO San Fernando de Atabapo, Edo. Amazonas.
NODO San Carlos de Ro Negro, Edo. Amazonas.
COMISOINADURIA Puerto Ayacucho, Edo. Amazonas.
NODO Machiques, Edo. Zulia.
NODO Santa Elena de Uairn, Edo. Bolvar
INIA El Tigre, Edo. Anzotegui.
NODO Porlamar, Edo. Nueva Esparta.
La Guaira, Edo. Vargas.
FUNDACITE San Cristbal, Edo. Tchira.
FUNDACITE Barquisimeto, Edo. Lara.
INIA Maturn, Edo. Monagas.
INIA Tucupita, Edo. Delta Amacuro.
INIA Valle de La Pascua, Edo. Gurico.
INIA San Felipe, Edo. Yaracuy.
FUNDACITE Coro, Edo. Falcn.
COMISIONADURIA Araure, Edo. Portuguesa.
FUNDACITE Valencia, Edo. Carabobo.
COMISIONADURIA San Carlos, Edo. Cojedes.
COMISIONADURIA Trujillo, Edo. Trujillo.
NODO Guasdualito, Edo. Apure.
INIA Caucagua, Edo. Miranda.
Tabla 8: Ubicacin de las salas de videoconferencia
____________________________________________________________________________

41
_________________________________________________________________________
A continuacin en la figura 23 un mapa de Venezuela con la ubicacin de las salas de
videoconferencia:
Ubicacin de los Nodos de Videoconferencia del CNTI
26
18
19
3
1
25
21
28
4
32
15
29
22
30
23
24
17
27
6
7
20
10
31
14
16
12
11
13
Figura 23: Mapa de Venezuela con la ubicacin de las salas de videoconferencias
____________________________________________________________________________

42
_________________________________________________________________________
3.2.1. IDENTIFICACIN DE LA PLATAFORMA DE VIDEOCONFERENCIA:
Para efectos de este documento se refiere como plataforma de videoconferencia a todos los
equipos (Codec, MCU, Gatekeeper, Content Server) y aplicacin (TMS Tandberg
Management Suite) con los cuales es posible establecer las llamadas de videoconferencia de
manera efectiva y controlada.
De acuerdo a los requerimientos para los equipos de videoconferencia que se detallan en el
documento licitatorio, DESCA C.A. aport la siguiente solucin:
-
Codec: Tandberg 6000 MXP.
MCU: Tandberg.
Gatekeeper: Tandberg.
Para un eficaz funcionamiento del sistema de videoconferencia y adicional a los equipos

que aparecen en el documento licitatorio, DESCA C.A. gracias a su alianza estratgica con
Tandberg agreg a la solucin: un Tandberg Content Server y un TMS. Los cuales tienen la
funcin de facilitar la creacin de material multimedia y, controlar y gestionar todo el sistema
de videoconferencia, respectivamente. Es importante destacar que slo en el nodo principal
(CNTI), como en el nodo espejo en Miraflores se van a instalar los equipos MCU, Gatekeeper,
Content Server, codec y la aplicacin TMS; los nodos remotos dispondrn slo del codec
Tandberg.
Para mayor informacin sobre los requerimientos de los equipos segn el documento
licitatorio y la solucin planteada por DESCA C.A., ver el ANEXO 2: Requerimientos de las
plataformas IP y de videoconferencia
3.2.2. IDENTIFICACIN DE LA PLATAFORMA IP:
Para efectos de este documento, se refiere como plataforma IP a todos los parmetros y
equipos con los cuales es posible establecer las conexiones de red. Los parmetros (tecnologa
de enlace, interfaz de ltima milla, esquema de direccionamiento IP de la WAN, tiempo de
respuesta y ancho de banda) son definidos por el cliente y los equipos de red son definidos por
DESCA C.A. de acuerdo a los requerimientos detallados en el documento licitatorio. La
calidad de servicio es establecida por DESCA C.A. desde los equipos terminales o codecs, sin
____________________________________________________________________________

43
_________________________________________________________________________
embargo, DESCA C.A. no tiene control y tampoco es responsable de la calidad del enlace
WAN seleccionado por el cliente. El esquema de direccionamiento IP de la LAN es definido
por DESCA C.A. segn sea conveniente.
A continuacin se puntualizan cada uno de los parmetros y equipos de red:
-
Tecnologa de Enlace: Satelital.
Interfaz de ltima milla: Ethernet 10/100 BT.
Esquema de direccionamiento IP de la WAN: sin clase o classless (implementacin de

VLSM), con mscara de subred 255.255.255.192, es decir, se disponen de 62 direcciones
utilizables para la subred asignada.
Tiempo de respuesta: Se garantizan 750ms entre el Hub satelital y las estaciones remotas
(para una llamada de videoconferencia se recomienda que el tiempo de respuesta end to
end de los enlaces satelitales no sea mayor a 500ms, por recomendacin de Tandberg).
-
Capacidad del canal para los nodos remotos: 512Kbps (Informacin suministrada por la
Ing. Glenys Monasterios de CVG Telecom).
Ancho de banda para los nodos remotos: 8MHz.
Capacidad del canal para el nodo principal: 10Mbps.
Ancho de banda para el nodo principal: 10,5MHz.
Equipos de red:
i. Switch: Cisco Catalyst Express WS-CE500-24LC
ii. Router: Cisco 2801
iii. Access Point: Cisco Aironet AP1100
Calidad de Servicio: Se define luego de realizar pruebas en el nodo de prueba (ver

subcaptulo 3.1.6)
____________________________________________________________________________

44
_________________________________________________________________________
3.2.3. TOPOLOGA DE LOS NODOS, DIAGRAMA DE LA RED Y DIAGRAMA DEL

RACK:
A continuacin en las figuras 24, 25 y 26 se muestran las topologas de conexin de los

nodos principal, remoto y porttil (la topologa del nodo mvil es igual a la del remoto):
Figura 24: Topologa nodo principal
____________________________________________________________________________

45
_________________________________________________________________________
Figura 25: Topologa nodo remoto o mvil
Figura 26: Topologa nodo porttil
____________________________________________________________________________

46
_________________________________________________________________________
El diagrama de la red de videoconferencia implementada se muestra en la figura 27:
Diagrama de Red de Videoconferencia del CNTI

Nodo porttil
Enlaces Satelitales
Nodo Remoto
Nodo Espejo
Miraflores
Nodo porttil
Nodo mvil
Nodo Remoto
Nodo Principal
CNTI
Figura 27: Diagrama de la red de videoconferencia del CNTI
____________________________________________________________________________

47
_________________________________________________________________________
El diagrama del rack se muestra en la Figura 28, y en las Fotos 1 y 2 el rack instalado:
Figura 28: Diagrama del rack
____________________________________________________________________________

48
_________________________________________________________________________
Foto1: Rack instalado (se muestra en el
Foto 2: Rack instalado (se muestra en el
lado izquierdo del diagrama de la Figura 28)
lado derecho del diagrama de la Figura 28)
3.2.4. INSPECCIN PRELIMINAR Y ADECUACIN DE LAS SALAS:
Antes de proceder a realizar las instalaciones se hicieron visitas a cada uno de los lugares
destinados para las salas de videoconferencia y hacer los llamados sites surveys, en los cuales
se documenta toda la informacin relevante del lugar (estado del piso, paredes, puntos de
corriente, puntos de red, salas de conexiones, etc.) con el motivo de tener idea de las
condiciones en las que se encontraban las salas, previniendo problemas y/o atrasos que
pudiesen afectar en gran medida la culminacin del proyecto en el tiempo acordado.
____________________________________________________________________________

49
_________________________________________________________________________
Como ejemplo, se presentan a continuacin dos casos de estudio del INIA (Instituto
Nacional de Investigaciones Agrcolas) en las localidades de San Felipe y Maracay:
INIA San Felipe:

Se realizaron inspecciones tanto del rea destinada a ser la sala de videoconferencia, como
la sala de conexiones. Esta ltima es el lugar donde se encuentran los racks que contienen los
equipos o dispositivos que sustentan la red (por ejemplo: switch, router, UPS, servidores, etc.).
La situacin en que se encontraba el rea destinada a ser sala de videoconferencia era bastante
inadecuada, a continuacin se indican caractersticas del sitio:
-
No existen puntos de red.
No se posee aire acondicionado.
La iluminacin es inadecuada (bombillos de rosca ahorradores de energa), adems de

poseer grandes ventanas que dejan pasar la luz exterior (no se poseen cortinas).
El piso est en mal estado (existen cermicas levantadas y rotas).
El techo est en mal estado (techo falso con lminas faltantes).
Existe una pared falsa de tabiquera.
Filtraciones en las paredes.
Falta pintura en las paredes.
Se piensa hacer una entrada de acceso, ya que las que poseen son inadecuadas.
Existen 8 tomas de corriente.

Con respecto a la sala de conexiones:
Se posee un buen aterramiento.
Los cables de red en los racks no se encuentran instalados de manera correcta.
La sala se comparte con trabajadores de otras reas, es decir, la sala no es exclusivamente

de conexiones, por lo que no existen las condiciones adecuadas.
Se posee una conexin Frame Relay (4E1).
Se poseen dos racks (uno para servicios de voz y el otro para datos).
Cada rack posee UPS en caso de fallas en el suministro de energa.
Se maneja un direccionamiento IP clase C, con el rango 192.168.19.5 a 192.168.19.254.
No se maneja VLAN.
No se posee firewall.
____________________________________________________________________________

50
_________________________________________________________________________
A continuacin la fotos 3 de la sala destinada para videoconferencia y la foto 4 de la sala
de conexiones, respectivamente:
Foto 3: Sala destinada para videoconferencia (San Felipe)
Foto 4: Sala de conexiones (San Felipe)
INIA Maracay:
Al igual que la inspeccin realizada en San Felipe, en esta localidad se revisaron las salas
destinadas a videoconferencia y de conexiones. Cabe destacar que INIA Maracay es la sede

principal donde se encuentra la gerencia general, y todos los dems INIAs son dependencias,
tanto jerrquicamente como a nivel de red. Esta sede se encuentra en excelente estado, las
condiciones de la sala de conexiones son adecuadas as como tambin la sala destinada a
colocar los equipos de videoconferencia (la sala est actualmente activa, es decir, la sala se usa
____________________________________________________________________________

51
_________________________________________________________________________
para dar cursos y realizar conferencias). Algunas caractersticas relevantes de la sala de
conferencia son:
-
Existen dos puntos de red.
Posee aire acondicionado.
Posee iluminacin adecuada. Y posee pequeas ventanas con cortinas.
El piso, techo y paredes se encuentran en buen estado.
Se disponen de dos pizarras de uso mltiple.
Existen 8 tomas de corriente.

Con respecto a la sala de conexiones:
Se posee un buen aterramiento.
Instalacin correcta de los cables de red en los racks.
La sala es de uso exclusivo para conexiones de toda la red.
Se maneja VLAN.
Se poseen direcciones 192.168.110.X.
No se posee firewall.
Se maneja Frame Relay. En un futuro se va a disponer de 1E3.
Se van a instalar switchs ms eficientes marca Cisco, ya que se poseen de otras marcas.
A continuacin la Fotos 5 de la sala destinada para videoconferencia y la Foto 6 de la sala
de conexiones, respectivamente:
Foto 5: Sala destinada para videoconferencia (Maracay)

____________________________________________________________________________

52
_________________________________________________________________________
Foto 6: Sala de conexiones (Maracay)
Luego de la inspeccin preliminar de todas las localidades se procede a realizar la

adecuacin de las salas por parte de Sonex de Venezuela C.A., empresa contratada por
DESCA C.A. para el acondicionamiento de las salas en el aspecto fsico o estructural, audio y
video. En general, las salas deben tener las siguientes caractersticas de acuerdo al documento
licitatorio:
-
Acondicionamiento fsico en las salas que lo requieran (hacer techos, pisos, paredes, tomas
de corriente, etc.).
Alfombrado.
Sillas y mesas para los participantes.
Aire acondicionado.
Iluminacin adecuada con lmparas de videoconferencia.
Sala de racks.
Cableado de todos los equipos.
Equipos de video: monitores LCD en los racks, matriz de conmutacin de video,

escaladores, video beam, pantallas de plasma, pantalla elctrica, cmaras con control
remoto, selector de video y DVD.
Equipos de audio: amplificadores, procesadores digitales, autoparlantes, splitters,

mezclador de micrfonos, micrfonos inalmbricos y micrfono almbrico.
____________________________________________________________________________

53
_________________________________________________________________________
-
Regletas con proteccin variable de voltaje.
Reguladores de voltaje.
Interfaces de enrutamiento para laptops, red, AC y otras conexiones que se deban llevar a
los racks.
A continuacin la foto 7 de una sala acondicionada para videoconferencia:
Foto 7: Sala acondicionada para videoconferencia
3.2.5. INSTALACIN DEL NODO DE PRUEBA:
Con el motivo de realizar pruebas al sistema de videoconferencia a implementar para el

CNTI, se instal un nodo de pruebas o laboratorio en DESCA C.A. el cual simula dos
localidades geogrficamente distantes. De esta manera, segn los parmetros establecidos por
CVG Telecom (empresa contratada por CNTI para realizar los enlaces satelitales), se
configuraron los equipos, se disearon protocolos de prueba y se crearon plantillas para la
configuracin en serie de los equipos en todas las localidades. Estos parmetros son:
capacidad del canal, tiempo de respuesta entre el hub satelital y las estaciones remotas,
interfaces de ltima milla y rango de direcciones IP para la WAN, los cuales fueron descritos
en el subcaptulo 3.1.2.
Bsicamente la topologa de red sobre la cual se quera hacer las pruebas es la que se
muestra en la figura 29, sin embargo, el laboratorio que se instal en DESCA C.A. (en la
____________________________________________________________________________

54
_________________________________________________________________________
pgina 58 se encuentra la topologa instalada) simula esta situacin, mas no posee la misma
topologa.
Figura 29: Topologa de red que se quiere simular
Para la implementacin del laboratorio se dispuso de:

-
Dos (2) Routers Cisco 2801.
Dos (2) Codec Tandberg 6000 MXP.
Un (1) Switch Cisco Catalyst Express WS-CE500-24LC.
Dos (2) pantallas de televisor.
Dos (2) cmaras 770 MXP.
Cables de red (cuatro directos, uno cruzado y dos traspuestos).
Cables de alimentacin para cada dispositivo.
Cables de video para las pantallas.
Cable serial para las cmaras.
Computadoras personales.
El primer paso fue la revisin del sistema operativo IOS (Internetwork Operating System,
por sus siglas en ingls) que poseen los routers por defecto, es decir, los que vienen instalados
____________________________________________________________________________

55
_________________________________________________________________________
en los equipos por el fabricante, y as verificar si las caractersticas del mismo permiten cubrir
los requerimientos de una llamada de videoconferencia. Para la revisin, es necesario
establecer una conexin serial con un cable de red transpuesto o de consola entre el puerto de
consola del router y el puerto serial de la computadora (es necesario un adaptador RJ-45 a
DB-9 para conectarse al PC). En la PC se debe tener un software de emulacin terminal ASCII
(se us Secure CRT 3.3, pero tambin se puede usar HyperTerminal el cual viene integrado
al Windows). Para conectar un PC a un router se realiza el siguiente procedimiento:
1) Se configura el software de emulacin Terminal en la PC (puerto COM adecuado,
9600 baudios, 8 bits de datos, sin paridad, 1 bit de parada, sin control de flujo).
2) Se conecta el extremo RJ-45 del cable transpuesto al puerto de consola del router. (El
puerto de consola es un puerto de administracin que se utiliza para proveer acceso al
router fuera de banda. Se usa para la configuracin inicial de router, monitoreo y

procedimientos de recuperacin en caso de desastres).
3) Se conecta el extremo DB-9 del cable transpuesto al puerto serial del PC (en este caso
se us un cable adaptador USB-Serial porque la laptop no posea puerto serial). A
continuacin en la Foto 6, se muestra la conexin de la PC al Router:
Puerto
USB
de la PC
Puerto de
Cnsola RJ-45
Extremo DB-9 del

cable de cnsola
Cable adaptador
Serial-USB
Foto 8: Conexin PC al router

Una vez dentro de la interfaz de configuracin CLI (Interfaz de la Lnea de Comando) del
router, se procede a introducir el username y el password. Para obtener la informacin del

____________________________________________________________________________

56
_________________________________________________________________________
IOS se introduce el comando show version, el cual adems de mostrar la versin del IOS,
muestra la memoria RAM, la plataforma sobre la cual trabaja y otras caractersticas relevantes
del dispositivo. La versin del software Cisco IOS que poseen los routers es 12.4 (1c) y el
nombre del archivo que est en la memoria flash es c2801-ipbase-mz.124-1c.bin. Con esta
informacin se revisa y confirma en la pgina de Cisco (http://www.cisco.com/public/swcenter/sw-ios.shtml) que el IOS posee las caractersticas de calidad de servicio (QoS)
necesarias para establecer una llamada de videoconferencia.
Luego en el CLI del router:
-
Se asigna un hostname.
Se habilitan las interfaces fastethernet 0/0 y 0/1.
Se habilita el protocolo de enrutamiento EIGRP (Enhanced Interior Gateway Routing
Protocol). Las razones de usar este protocolo son las siguientes: resulta ms conveniente
porque es un protocolo patentado por Cisco y todos los equipos de red que se van a usar
son de la mencionada marca; la red que se va a implementar es relativamente pequea y la
mtrica de enrutamiento abarca toda la red (por ejemplo: RIP posee 15 saltos como
mtrica y no podra abarcar las 32 localidades); tiene la capacidad de conocer las tablas de
enrutamiento de routers adyacentes (este protocolo es un hbrido de protocolos de
enrutamiento vector-distancia y estado de enlace).
Se deshabilita la opcin de auto-summary del protocolo de enrutamiento que por defecto
est habilitada, ya que es recomendado en redes no tan extensas para que todos los
dispositivos puedan verse en su totalidad.
-
Se asignan las direcciones IP a cada interfaz: la 0/0 se asigna para la WAN y la 0/1 para la
LAN.
Se aplican las polticas de calidad de servicio a la interfaz WAN.
Se usa el comando show ip interface brief para verificar las direcciones IP asignadas y
que las interfaces y protocolos se encuentren levantados.
Se usa el comando show ip eigrp neighbors para verificar que los routers se hayan
reconocido como usuarios de EIGRP.
Se usa el comando show ip route para verificar todas las rutas IP que posee el router.
____________________________________________________________________________

57
_________________________________________________________________________
Seguidamente para poder simular dos localidades y disponiendo de un slo switch, se
crearon en este ltimo dos Redes de Acceso Local Virtuales o VLAN. La topologa de
conexin se muestra en la figura 30:
Figura 30: Topologa de red simulada
En la interfaz de configuracin del switch:

-
Se le asigna un nombre al switch.
El rol de cada puerto (Ej. Puertos 1 al 4 son para conectar Access Point, el 3 y 4 para
router, etc.)
-
Se establece la velocidad en Mbps y el modo de transmisin (duplex, full duplex, etc.)
Se cre una VLAN adicional a la que est por defecto en el equipo (los puertos 1 al 12
pertenecen a la VLAN1 y los puertos 13 al 24 a la VLAN2).
A cada VLAN se le asigna una direccin IP y un Default Gateway, este ltimo es la

direccin IP del router correspondiente.
Con respecto al codec Tandberg, se configur lo siguiente:

-
La direccin IP, su mscara de subred y el default gateway.
El idioma del men a espaol.
____________________________________________________________________________

58
_________________________________________________________________________
-
Se lo asign un nombre al codec.
Se estableci que respondiera las llamadas automticamente.
En la calidad de servicio, se establecieron precedencias de 4 para sealizacin y 5 para

audio y video (se explica con ms detalle en el siguiente captulo).
Con respecto a los parmetros del Gatekeeper, MCU y TMS, no se configuraron ya que no
se dispona de los equipos.
El laboratorio se realiz sin hacer uso del Access Point debido a que estos no eran
relevantes para la videoconferencia, sino que son un agregado para que en las salas de
videoconferencia los participantes puedan disponer de acceso inalmbrico a Internet.
Luego de realizar la instalacin y configuracin de todos los equipos, se estableci un

protocolo de pruebas el cual consiste en lo siguiente:
-
Asignarle una direccin IP a una PC dentro del rango de la LAN que se quiera probar, la
mscara y el default gateway.
Conectarse a cualquier puerto del switch (asignado para computadoras o desktop).
Abrir el Command Prompt o Smbolo del Sistema en la computadora.
Hacer ping a las direcciones IP correspondientes al codec, switch y router de cada

localidad instalada, de esta manera se verifican conexiones y correcta configuracin de
direccionamiento.
Realizar pruebas de llamadas en ambos sentidos (en caso de que en la sala no disponga
todava de conexin WAN, probar llamadas con un laptop usando el NetMeeting).
Verificar que el video sea fluido y con poco o ningn retardo.
Verificar que el audio no posea eco ni feedback. (El eco se define como remoto, mientras
que el feedback se define como local, ya que este ltimo es la retroalimentacin de las
cornetas y micrfonos locales. Por el contrario el eco es cuando el sonido trasmitido se
devuelve nuevamente por el micrfono de la sala con la cual se est realizando la
videoconferencia).
Verificar la correcta conexin a tierra de los racks en los cuales se encuentran instalados
los equipos para evitar ruido en las seales, esttica en los circuitos, proteccin en caso de
lluvias con descargas elctricas, etc.
____________________________________________________________________________

59
_________________________________________________________________________
A continuacin en la figura 31, se muestra una captura de pantalla de los ping realizados
en una prueba del laboratorio:
Figura 31: Captura de pantalla de los ping realizados en una prueba del laboratorio
Las direccines IP que terminan en 1 pertenecen a los routers y las que terminan en 3
pertenecen a los codecs.
____________________________________________________________________________

60
_________________________________________________________________________
3.2.6. APLICACIN DE CALIDAD DE SERVICIO Y DISTRIBUCIN DE ANCHO

DE BANDA:
La calidad de servicio o QoS (Quality of Service) es la garanta de que se trasmitan cierta

cantidad de datos en un tiempo dado. Se puede usar en redes LAN o WAN privadas para su
manejo ms efectivo y en momentos de alta cantidad de trfico en la red, la implementacin
de QoS ayuda a que los equipos mantengan la estabilidad y ofrezcan alta probabilidad de que
la data de videoconferencia llegue a su destino.
Los equipos Tandberg poseen una caracterstica siempre activa llamada Recuperacin
Inteligente de Prdida de Paquetes o IPRL (Intelligent Packets Lost Recovery), la cual tiene la
habilidad incrementar la robustez de la rfaga de bits transmitidos, la imagen recibida y de
reducir la tasa de la llamada si es detectada una excesiva prdida de paquetes (1-2%). Todas
estas cualidades son compatibles con los estndares ITU-T. Esta caracterstica no reemplaza
las tcnicas de calidad de servicio que se puedan emplear en las redes IP para reservar ancho
de banda o establecer precedencia en el trfico de video, sino que en el raro caso que la calidad
de servicio falle, el IPRL esta diseado para reducir el impacto de la prdida de paquetes en el
trfico de video. Adems, el IPRL es la primera tcnica de recuperacin de paquetes basada en
los algoritmos de video H.261, H.263 y H.264(31).
El equipo Tandberg 6000 MXP con el que se trabaj dispone de varias tcnicas para la
implementacin de calidad de servicio:
-
RSVP (Resource ReSerVation Protocol): es un estndar usado por los puntos

terminales para solicitar cierta calidad a la red en la cual se van a transportar los datos
de audio y video.
Servicios Diferenciales (en ingls: Differential Services): Esta tcnica consiste en usar
6 bits del byte de tipo de servicio, con lo cual se dispone de un rango de 0 a 63
parmetros configurables por el usuario para valores de control, audio y video.
Precedencia IP y Tipo de Servicio: la precedencia IP permite a los terminales darle

prioridades a los paquetes de audio y video, por encima o por debajo de otro trfico IP
en la misma red. El Tipo de Servico o ToS es usado por los routers para que tomen
decisiones de cmo manejar el trfico si ocurre alguna congestin.
____________________________________________________________________________

61
_________________________________________________________________________
La tcnica implementada y que mejor se ajusta para el tipo de configuracin que se
dispone en este proyecto es la precedencia IP, y adems resulta compatible con el router al
aplicarle las correctas polticas de calidad de servicio en la interfaz WAN (interfaz por la que
se envan los paquetes de audio y video).
Para la asignacin del ancho de banda es necesario saber que las llamadas de
videoconferencia H.323 son divididas en rfagas de audio y video, lo que implica ocupaciones
del canal distintas (generalmente el audio usa 48Kbps o 64Kbps y el video flucta segn las
variaciones que tenga la imagen a ser transmitida). Por ejemplo, en una llamada de 384Kbps la
ocupacin aproximada del video es de 320Kbps y del audio es de 48Kbps. Sin embargo, con la
sobrecarga IP, la capacidad del canal total alcanza sobrepicos de 460Kbps. Por lo que
dependiendo de las variaciones del video la capacidad del canal flucta entre 384Kbps y
460Kbps, es decir, un 20% aproximadamente(32). A continuacin la combinacin recomendada
de capacidad del canal de llamadas H.323 y capacidad del enlace:
-
Videollamadas de 384Kbps en enlaces de 512Kbps (esta es la recomendacin mnima

para una videoconferencia).
Videollamadas de 512Kbps en enlaces de 768Kbps.
Para los equipos Tandberg 6000 MXP se recomienda y establece por defecto si el
administrador no lo define, que la velocidad de las llamadas sea de 768kbps en llamadas
H.323. Sin embargo, es posible establecer llamadas a 256kbps, 192kbps y 128kbps pero la
calidad y fluidez de la llamada no ser ptima.
La aplicacin de la calidad de servicio o QoS comienza en el codec asignndole
precedencia crtica a los paquetes de media (audio y video) y precedencia flash-override a
los paquetes de sealizacin. Luego stos paquetes son identificados por el router y se asignan
a una lista de acceso, que a su vez es asignada a una clase y con sta se crea una poltica
de prioridades para la interfaz fastethernet WAN. Debido a que la capacidad del canal
asignada es de 512Kbps y adicional a la llamada H.323 se van a transmitir datos
(presentaciones en PowerPoint, etc.), no es posible asignar 384Kbps como se explic
anteriormente, porque la transmisin de datos sera ineficiente, por lo que se distribuyen
256Kbps para audio y video, 8Kbps para sealizacin y el restante de 248Kbps o menos para
datos.
____________________________________________________________________________

62
_________________________________________________________________________
A continuacin se detalla el proceso para la implementacin de calidad de servicio:
1. En la interfaz de configuracin del codec Tandberg se aplica calidad de servicio (QoS),
ubicada en la opcin H.323 dentro de la pestaa superior System configuration. Se
establece la precedencia de Videotelephony Audio y Videotelephony Video en 5 o
crticas y Videotelephony Signalling en 4 o flash-override. A continuacin en la
Figura 32, se muestra la captura de la pantalla:
Figura 32: Calidad de Servicio en codec Tandberg
2. En la configuracin del router se crean las listas de acceso, donde se identifican todos los
paquetes procedentes de la DIRECCIN IP del codec, con precedencia crtica o flash-
override y se asignan a una lista de acceso con nombre de Media o Signaling,

correspondientemente segn la precedencia:
ip access-list extended Media
permit ip host DIRECCIN IP any precedence critical
ip access-list extended Signaling
permit ip host DIRECCIN IP any precedence flash-override
3. Se crean las clases o class-map, las cuales identifican las listas de acceso:
class-map match-all Media
____________________________________________________________________________

63
_________________________________________________________________________
match access-group name Media
class-map match-all Signaling
match access-group name Signaling
4. Se crea la poltica y se le asigna un nombre (en este caso VC-LLQ), donde se identifican
las clases y se les asignan las prioridades de uso del ancho de banda, para el envo de
paquetes:
policy-map VC-LLQ
class Media
priority 256
class Signaling
bandwidth 8
En el cdigo se observa que para la clase Media la cual abarca los paquetes de audio y
video, se garantiza una mnima capacidad de transmisin de 256Kbps con el comando
priority y se establece una capacidad del canal de 8Kbps para la clase Signaling, la cual
abarca los paquetes de sealizacin.
5. Finalmente se aplica la poltica VC-LLQ a la interfaz fastethernet WAN:

interface FastEthernet0/0
bandwidth 512
ip address DIRECCIN-IP MSCARA-DE-RED
speed 100
full-duplex
service-policy output VC-LLQ
Se observa en el cdigo que se aplica la poltica la interfaz y se especifica con el comando

output que sta es slo para los paquetes salientes.
Es importante resaltar que sta fue la tercera alternativa para aplicar calidad de servicio,
debido a que idealmente se quera aplicar QoS en el switch por ser ste un dispositivo de capa
2 (modelo de referencia OSI), es decir, se quera filtrar los paquetes o asignarles prioridades
en el nivel ms bajo antes de que se transmita la informacin a capas superiores, permitiendo
que el sistema sea ms eficiente. Sin embargo, el sistema operativo del switch no permite
configurar calidad de servicio. Una segunda alternativa, conociendo los puertos del codec por
los cuales salen los paquetes TCP y UDP correspondientes a video, audio y sealizacin
(informacin obtenida de Tandberg), era configurar el router para que identifique todos los
____________________________________________________________________________

64
_________________________________________________________________________
paquetes provenientes de dichos puertos y asignarles prioridades como se explic
anteriormente; pero realizando pruebas se observ que haba retardos en las imgenes
transmitidas, por lo que se ejecutaron los siguientes comandos en la interfaz de lnea de
comandos o CLI de router:
-
show access-list para verificar los puertos en las listas de acceso.
show running-config para verificar la configuracin actual del router (interfaces,

polticas aplicadas, etc.).
show policy-map interface para revisar si hay drops o prdida de paquetes.
Se determin que: las listas de acceso tenan los puertos correctos, las interfaces estaban
levantadas y con las correctas polticas y, no haban drops. Esto se deba a que no se estaban
identificando los paquetes provenientes del codec, por lo que se presume que los puertos
indicados por Tandberg estn errados y el router no los reconoca.
____________________________________________________________________________
Captulo 4: Verificacin de llamadas de videoconferencia IP

_________________________________________________________________________
CAPTULO 4: VERIFICACIN DE LLAMADAS

DE VIDEOCONFERENCIA IP
4.1. PASOS DE UNA LLAMADA DE VIDEOCONFERENCIA IP:
En general, una llamada de videoconferencia H.323 sigue cuatro pasos:

1) Establecimiento de la llamada: Uso de mensajes de sealizacin H.225 (Setup,
CallProceding, Alerting y Connect). En el caso de la presencia de un gatekeeper, existen

intercambios de mensajes RAS con el mismo. El puerto TCP usado en el origen es
asignado dinmicamente en el rango 1024 al 65535 y el puerto TCP destino es el 1720; los
mensajes RAS con el gatekeeper usan el puerto 1719 y para el gatekeeper discovery se usa
el 1718(33).
2) Flujos de Sealizacin de Control o Negociacin de Parmetros: Uso de mensajes de
control H.245 entre los terminales para determinar quin es el Master y quin es el Slave,
la capacidad de los terminales (velocidad de transmisin, etc.) y los codec de audio y video
a ser usados (mensajes: TerminalCapabilitySet y MasterSlaveDetermination). Cuando se
finaliza la negociacin se abren los canales o puertos de comunicacin (mensajes:
OpenLogicalChannel). Uso de puertos UDP en el rango 1024 al 65535.

3) Flujo de rfagas de media y control de media: Se inicia la comunicacin entre los
participantes (audio y video) usando los protocolos RTP/RTCP. Uso de puertos UDP en el
rango 1024 al 65535.
4) Liberacin de la llamada: El terminal que llama o el llamado puede iniciar el proceso de
finalizacin de la llamada. Se usan mensajes de control H.245 (EndSessionCommand y
CloseLogicalChannel) y de sealizacin H.225 (ReleaseComplete). Se usan los mismos

puertos con los cuales se estableci y negoci la llamada.
A continuacin se muestran las figuras 33, 34, 35 y 36 en las que se pueden observar los
pasos que se siguen durante una llamada H.323. El ejemplo est compuesto de dos puntos
terminales H.323 (T1 y T2) conectados a un gatekeeper (se asume llamada directa de
sealizacin). Para el caso en el que se establezca la llamada sin presencia de un
gatekeeper, considerar el mismo diagrama pero sin los pasos 1, 2, 5, 6, 24 y 25.

____________________________________________________________________________

66
_________________________________________________________________________
1) Establecimiento de la llamada H.323:
Figura 33: Paso 1 (establecimiento de la llamada H.323)
1.1)
T1 enva mensajes RAS ARQ en el canal RAS hacia el gatekeeper para el registro. T1
solicita el uso de llamada directa de sealizacin
1.2)
El gatekeeper confirma la admisin de T1 mediante el envo de ACF a T1. El
gatekeeper le indica en el ACF a T1 que puede usar llamada directa de sealizacin.

1.3)
T1 enva un mensaje de configuracin de sealizacin de llamada H.225 a T2

solicitando conexin.
1.4)
T2 responde con un mensaje de aceptacin de llamada (call proceeding) H.225 a T1.
1.5)
Ahora que T2 se ha registrado con el gatekeeper, este enva un mensaje RAS ARQ al
gatekeeper sobre el canal RAS.

1.6)
El gatekeeper confirma el registro mediante el envo del mensaje RAS ACF a T2.
1.7)
T2 alerta a T1 del establecimiento de la conexin mediante el envo del mensaje de

alerta H.225.
1.8)
Luego el T2 confirma el establecimiento de la conexin mediante el envo del mensaje

de conexin H.225 a T1, y la llamada se establece.
____________________________________________________________________________

67
_________________________________________________________________________
2) Flujos de Sealizacin de Control o Negociacin de Parmetros H.323:
Figura 34: Paso 2 (Flujos de Sealizacin de Control o Negociacin de Parmetros H.323)
2.1) Se establece el canal de control H.245 entre T1 y T2. El T1 enva un mensaje
TerminalCapabilitySet a T2 para el intercambio de capacidades.

2.2) T2 reconoce las capacidades de T1 mediante el envo del mensaje H.245
TerminalCapabilitySetAck.
2.3) T2 intercambia sus capacidades con T1 mediante el envo del mensaje H.245
TerminalCapabilitySet.
2.4) T1 reconoce las capacidades de T2 mediante el envo del mensaje H.245
TerminalCapabilitySetAck.
2.5) T1 abre un canal de media con T2 mediante el envo del mensaje H.245
OpenLogicalChannel. La direccin de transporte del canal RTCP est incluida en el

mensaje.
2.6) T2 reconoce el establecimiento del canal lgico unidireccional de T1 a T2 mediante el
envo del mensaje H.245 OpenLogicalChannelAck. La direccin de transporte RTP est
____________________________________________________________________________

68
_________________________________________________________________________
incluida en el mensaje de reconocimiento, asignada por T2 para ser usada por T1 para el
envo de rfagas de media RTP y la direccin RTCP recibida anteriormente de T1.
2.7) Luego T2 abre un canal de media con T1 mediante el envo del mensaje H.245
OpenLogicalChannel. La direccin de transporte del canal RTCP est incluida en el

mensaje.
2.8) T1 reconoce el establecimiento del canal lgico unidireccional de T2 a T1 mediante el
envo del mensaje H.245 OpenLogicalChannelAck. La direccin de transporte RTP est
incluida en el mensaje de reconocimiento, asignada por T1 para ser usada por T2 para el
envo de rfagas de media RTP y la direccin RTCP recibida anteriormente de T2.
Ahora se ha establecido una comunicacin bidireccional de rfagas de media.
3) Flujo de rfagas de media y control de media H.323:

Gatekeeper
T1
T2
RTP Media Stream (17)
RTP Media Stream (18)
RTCP Message (19)
RTCP Messages (20)
Rfagas de media RTP y mensajes RTCP
Figura 35: Paso 3 (Flujo de rfagas de media y control de media H.323)
3.1)
T1 enva la rfaga de media encapsulada por RTP hacia T2.
3.2)
T2 enva la rfaga de media encapsulada por RTP hacia T1.
3.3)
T1 enva los mensajes RTCP hacia T2.
3.4)
T2 enva los mensajes RTCP hacia T1.
____________________________________________________________________________

69
_________________________________________________________________________
4) Liberacin de la llamada H.323:
Gatekeeper
T1
End Session Command (21)
End Session Command (22)
Release Complete (23)
DRQ (24)
DRQ (24)
DCF (25)
DCF (25)
H.225Mensaje Sealizacin
Mensaje RAS
Mensaje H.245
Figura 36: Paso 4 (Liberacin de la llamada H.323)
4.1)
T2 inicia el proceso de liberar de la llamada, mediante el envo del mensaje H.245
EndSessionCommand hacia T1.

4.2)
T1 libera la llamada del punto terminal y confirma la misma mediante el envo del
mensaje H.245 EndSessionCommand hacia T2.
4.3)
T2 completa la liberacin de llamada mediante el envo del mensaje H.225 de

liberacin completa a T1.
4.4)
T1 y T2 se desenganchan del gatekeeper mediante el envo del mensaje RAS DRQ

hacia el gatekeeper.
4.5)
El gatekeeper desengancha a T1 y T2 y lo confirma enviando mensajes DCF a cada

uno de los terminales.
A continuacin la tabla 9, en la que se muestran los puertos que usan los terminales H.323
durante una llamada de videoconferencia (Terminal, MCU y gatekeeper)(33):
____________________________________________________________________________

70
_________________________________________________________________________
Puerto
1502
Tipo de
Protocolo
TCP esttico
Descripcin
Terminal
H.323
x
MCU
H.323
x
Gatekeeper
H.323
T.120
Gatekeeper
1718
UDP esttico
x
x
x
dicovery
1719
UDP esttico Gatekeeper RAS
x
x
x
TCP/UDP Establecimiento
1720
x
x
esttico
llamada h.225
UDP
Parmetros
1024 al 65535
x
x
dinmico
H.245
UDP
RTP (Rfagas de
1024 al 65535
x
x
dinmico
data de Video)
UDP
RTP (Rfagas de
1024 al 65535
x
x
dinmico
data de Audio)
RTCP
UDP
(Informacin de
x
x
1024 al 65535
dinmico
Control)
Tabla 9: Puertos que usan los terminales H.323 durante una llamada de videoconferencia
(Terminal, MCU y Gatekeeper)
A continuacin las tablas 10 y 11, en la que se muestran los puertos que usan los codec
Tandberg MXP6000 durante una llamada de videoconferencia punto a punto y multipunto(34),
respectivamente:
Puerto
Tipo
Funcin
1719
UDP
Gatekeeper Discovery
1720
TCP
Q.931 Call Setup
5555-5574
TCP
H.245
2326-2341
UDP
Video
2326-2341
UDP
Audio
2326-2341
UDP
Data/FeCC
Tabla 10: Puertos que usa el codec Tanberg 6000MXP en una llamada punto a punto
Puerto
Tipo
Funcin
1719
UDP
Gatekeeper Discovery
1720
TCP
Q.931 Call Setup
5555-5574
TCP
H.245
2326-2405
UDP
Video
2326-2405
UDP
Audio
2326-2405
UDP
Data/FeCC
Tabla 11: Puertos que usa el codec Tanberg 6000MXP en una llamada multipunto.
____________________________________________________________________________

71
_________________________________________________________________________
4.1.1. CAPTURA DE TRFICO DE LLAMADAS H.323:
Con el objetivo de comprobar la revisin terica realizada anteriormente, se procedi a

realizar capturas de trfico de llamadas H.323 usando la aplicacin WireShark Version 0.99.3,
el cual es un analizador de protocolos de red, mejor conocido como sniffer. El uso de esta
aplicacin en una red permite capturar de manera promiscua y en tiempo real todo el trfico
que circula en la misma, las direcciones IP origen y destino, tipos de protocolos, informacin
detallada de los paquetes, formato hexadecimal de la informacin trasmitida, aplicacin de
filtros tanto de captura, como para ver slo los paquetes de inters, grfica de trazas, etc.
Se hicieron capturas de llamadas H.323 con los siguientes equipos terminales:
NetMeeting en PC,
Cliente Beacon H.323 en PC,
Servidor Beacon H.323 en PC y
Codec Tandberg 6000 MXP.
En los siguientes subcaptulos se detalla cada una de las pruebas realizadas con sus
respectivos comentarios y al final un anlisis de las capturas realizadas.
4.1.1.1. CAPTURA DE TRFICO USANDO TERMINALES NETMEETING:
La primera prueba realizada se hizo mediante una llamada de NetMeeting (aplicacin

H.323 que viene integrada al Windows) entre dos computadoras con cmara y micrfono:
1.) Para acceder al NetMeeting en una PC se selecciona Inicio, luego Ejecutar, se
escribe conf y se presiona Aceptar.
2.) Si se est ejecutando por primera vez es necesario seguir los pasos de configuracin,
sino el programa inicia automticamente.
Se instala el sniffer Wireshark, el cual est disponible gratuitamente en Internet en la
direccin www.wireshark.org. Para iniciar la captura de trfico:
1.) Presionar las teclas CTRL + k para abrir las opciones de captura.
2.) Seleccionar la interfaz en la que se va a capturar al trfico.
3.) Asegurarse que la casilla de Capture packets in promiscuous mode est seleccionada.
4.) Quitar cualquier filtro de captura que est activo.
____________________________________________________________________________

72
_________________________________________________________________________
5.) Presionar Start para iniciar captura.
6.) Realizar una llamada con el NetMeeting introduciendo la direccin IP del PC destino y
presionar el icono de Llamar.
7.) Esperar para que se capturen todos los paquetes de establecimiento, video, audio, etc.
8.) Finalizar la llamada en el NetMeeting en cualquiera de los PC y luego finalizar la
captura en el WireShark.
9.) Guardar la captura.
Para analizar especficamente la(s) llamada(s) H.323 presente(s) durante la captura, ya
que en sta se muestra todo el trfico sin excepcin que la PC transmite y recibe para el
momento, se siguen los siguientes pasos:
1.) En el WireShark se presiona la opcin Statistics y luego VoIP Calls para
identificar las llamadas IP realizadas durante la captura. A continuacin en la figura
37, la captura de pantalla:
Figura 37: Identificacin de llamadas IP en el WireShark
2.) Al abrir la ventana de las llamadas IP se seleccionan las que sean de inters. A
continuacin en la figura 38, la captura de pantalla:
____________________________________________________________________________

73
_________________________________________________________________________
Figura 38: Seleccin de llamadas IP en el WireShark
3.) Presionar Prepare Filter, para crear un filtro de display que muestre slo los paquetes
correspondientes a la(s) llamada(s) H.323.
4.) En la ventana principal, donde se encuentra la captura total de los paquetes, seleccionar
Apply para filtrar los paquetes (esta accin no modifica el archivo, slo los paquetes
que se muestran). A continuacin en la figura 39 la captura de pantalla:
Figura 39: Aplicacin de filtro de pantalla en el WireShark
Realizado el filtrado de paquetes es posible identificar y comprobar que en la prctica se

cumplen los pasos tericos de una llamada H.323 (descritos en el captulo 4). En la imagen
anterior las columnas enmarcadas en un cuadro verde indican las direcciones IP origen y
____________________________________________________________________________

74
_________________________________________________________________________
destino de cada paquete y, las enmarcadas en un cuadro rojo indican los protocolos e
informacin de los paquetes que se estn trasmitiendo entre los terminales. Entre otras cosas,
es posible identificar y corroborar el uso de puertos y tipos de protocolos que se usan durante
las llamadas H.323. Por ejemplo: en la figura 40, si se analiza el paquete H.225 Setup en el
establecimiento de la llamada, se observa que el tipo de paquete es TCP y que los puertos
origen y destino son 1042 y 1720, respectivamente:
Figura 40: Informacin disponible en el WireShark (usando NetMeeting)
Para mostrar en forma grfica el intercambio de paquetes de la llamada H.323, los puertos
usados en el origen y destino, etc., se presiona Graph en la ventana de las llamadas IP. A
continuacin en la figura 41 la captura de pantalla:
____________________________________________________________________________

75
_________________________________________________________________________
Direcciones IP origen y destino
Establecimiento de la llamada H.323

con el protocolo H.225
Negociacin de
Parmetros con
el protocolo
H.245
Flujos de rfagas
de media RTP
(los paquetes
H.245 son
miscelneos)
Liberacin de la
llamada H.323
con protocolos
H.225 y H.245
Puertos
Acciones
Comentarios
Figura 41: Traza de llamadas IP en el WireShark (usando NetMeeting)
____________________________________________________________________________

76
_________________________________________________________________________
A continuacin se muestra la tabla 12 con las observaciones de esta captura:
Pasos de la
llamada
1) Establecimiento
de la llamada
2) Flujos de
sealizacin de
control
Puertos Usados
Origen
Destino
1042
1043
Observaciones
1720
.- Ausencia del paquete H.225 CallProceding.

.- Puerto origen dentro del rango y puerto destino
correcto.
2165
.- El intercambio de paquetes H.245

TerminalCapabilitySet y OpenLogicalChannel no se
realizan en orden segn el modelo terico
.- Presencia del paquete H.245 OLCReject en
respuesta a la peticin H.245 OLC(t120) del origen.
.- Presencia de paquetes H.245
MiscellaneousCommand y OLCConfirm, los cuales
no se detallan en el modelo terico.
.- El destino inicia intercambio de paquetes OLC a
diferencia del modelo terico.
.- Puertos dentro del rango

3) Flujo de rfagas 49600 (Audio) 49600 (Audio)
MiscellaneousCommand.
de media
49598 (Video) 49598 (Video)
.- Puertos dentro del rango.
.- El intercambio y cantidad de paquetes H.225 y
4) Liberacin de la
Puertos usados en pasos 1) y 2) H.245 no se realiza segn el modelo terico.
llamada
.- Puertos correctos
Tabla 12: Observaciones de capturas de trfico usando NetMeeting
Para verificar estos resultados se realizaron varias llamadas usando el NetMeeting y en

general todas coincidan en las observaciones realizadas en la tabla 12. Obviamente los
puertos usados variaban, pero siempre dentro del rango.
Analizando el paquete H.245 OpenLogicalChannelReject, derivado ste de la peticin
H.245 OLC(t120) por parte del terminal origen, se observa que el sniffer no especifica el
motivo del rechazo (ver captura de pantalla en figura 42). Sin embargo, luego de realizar
varias pruebas se not que ambos terminales NetMeeting solicitan abrir un canal lgico para
t120, estndar ITU de data (ver anexo 1) que permite transmitir y recibir informacin de
manera segura (transferencia de archivos, conferencias con pizarra electrnica, etc.), pero slo
se abre en uno de ellos, y es necesario rechazar alguna de las peticiones por cualquiera de los
terminales. An as, el sistema funcionaba perfectamente y para comprobar este rechazo, se
realizaron transferencias de archivos en ambas direcciones de manera satisfactoria. Se
presume que es debido a la configuracin del fabricante, el hecho de que slo se abra un canal
lgico t120.
____________________________________________________________________________

77
_________________________________________________________________________
Figura 42: Anlisis del paquete H.245 OpenLogicalChannelReject en la captura usando

NetMeeting
Otro aspecto que se not al aplicar el filtro de display es que los paquetes RTCP no
aparecen, por lo que en la figura 43 se muestra una captura de pantalla con la lista de paquetes
sin el filtro de display aplicado (ntese que el campo de filter est vaco) para que se pueda
apreciar el envo y recepcin de paquetes de reporte RTCP (correspondiente al paso de flujo
de rfagas de media), as como tambin se observa y verifica que son paquetes UDP.
____________________________________________________________________________

78
_________________________________________________________________________
Figura 43: Captura de paquetes sin filtro de pantalla (usando NetMeeting)
4.1.1.2. CAPTURA DE TRFICO USANDO TERMINALES CLIENTE/SERVIDOR

BEACON H.323:
El H.323 Beacon es una herramienta de arquitectura distribuida cliente/servidor que puede

ser usada para medir, monitorear y calificar el desempeo de una sesin de videoconferencia
H.323, con la que se ayuda a usuarios, ingenieros de red y operadores de videoconferencia a
realizar troubleshooting de llamadas H.323. El cliente se refiere a un usuario final o nodo
remoto (slo es capaz de realizar llamadas H.323) y el servidor se puede ver como el nodo
principal (slo es capaz de recibir llamadas H.323). El inters de realizar capturas de trfico
durante el uso del cliente/servidor Beacon H.323 es tener un punto de vista distinto y
correcto de una llamada de videoconferencia, ya que esta aplicacin debera simular una
videoconferencia real y por tanto el intercambio de paquetes reales.
Para usar el Beacon H.323, descargar de forma gratuita las aplicaciones de cliente y
servidor Beacon H.323 de la pgina http://sourceforge.net/projects/h323beacon e instalarlas en
____________________________________________________________________________

79
_________________________________________________________________________
dos computadoras distintas (seguir los pasos de instalacin de cada una de las aplicaciones que
aparecen en los documentos de texto Readme).
Una vez realizada la instalacin en cada computadora:
1) Iniciar el cliente y el servidor Beacon H.323.
2) En el cliente se introduce la direccin IP de la PC donde se encuentra instalado el
servidor Beacon, el campo se llama H.323 Beacon Server IP.
3) Iniciar la captura de trfico con el sniffer WireShark.
4) Seleccionar la velocidad de la llamada y presionar Call.
5) Esperar a que se establezca la llamada y que el Beacon realice las mediciones
necesarias (aproximadamente 3-4 minutos). Si se quiere se puede grabar un mensaje de
voz, el cual se transmite y recibe entre el cliente y el servidor.
6) Terminar la llamada en el Beacon presionando Hang Up y esperar 15 segundos para
que pase el timeout del servidor y este proceda a completar el proceso de liberar la
llamada. NOTA: al finalizar la llamada el cliente Beacon ofrece la opcin de generar
un archivo de Excel con todos los datos que sirven para realizar las estadsticas de la
llamada (jitter, packet loss, round trip delay, etc.).
7) Finalizar la captura en el WireShark
8) Guardar la captura
Siguiendo el mismo procedimiento para analizar las llamadas H.323 presentes durante la
captura que se explic en el subcaptulo 4.1.1.1, se aplic el filtro de display y se obtuvo todo
el intercambio de paquetes que se realizaron durante la llamada para poder realizar su anlisis
y comprobar los pasos tericos. A continuacin en la figura 44, se puede observar entre otras
cosas que en el paquete H.225 Setup, se detalla la identificacin del producto con la que se
est realizando la llamada:
____________________________________________________________________________

80
_________________________________________________________________________
Figura 44: Identificacin del producto con el que est realizando la llamada
La traza o grfica de la llamada se muestra en la figura 45:
____________________________________________________________________________

81
_________________________________________________________________________
Figura 45: Traza de llamadas IP en el WireShark (usando cliente/servidor Beacon H.323)
____________________________________________________________________________

82
_________________________________________________________________________
A continuacin se muestra la Tabla 13 con las observaciones de esta captura:
Pasos de la
llamada
1) Establecimiento
de la llamada
2) Flujos de
sealizacin de
control
Puertos Usados
Origen
Destino
1573
1574
Observaciones
1720
.- Ausencia del paquete H.225 Alerting.

correcto
2744

realizan en orden segn el modelo terico
.- El destino inicia intercambio de paquetes OLC a
diferencia del modelo terico.

.- Presencia de paquetes H.225 Information.
5002 (Audio)
RoundTripDelayRequest y RoundTripDelayResponse.
3) Flujo de rfagas
de media
5000 (Audio)
4) Liberacin de la
llamada
.- El intercambio de paquetes H.225 y H.245 no se
Puertos usados en pasos 1) y 2)
realiza segn el modelo terico.
.- Presencia del paquete H.245 CloseLogicalChannel.
Tabla 13: Observaciones de capturas de trfico usando cliente/servidor Beacon H.323
Para verificar estos resultados se realizaron varias llamadas usando el cliente y el servidor
H.323 Beacon y en general todas coincidan en las observaciones realizadas en la Tabla 13.
Obviamente los puertos usados variaban, pero siempre dentro del rango.
____________________________________________________________________________

83
_________________________________________________________________________
4.1.1.3. CAPTURA DE TRFICO USANDO TERMINALES NETMEETING Y EL

SERVIDOR BEACON H.323:
Sustituyendo ahora el cliente Beacon H.323 por el NetMeeting, se procedieron a realizar

llamadas al servidor Beacon para de esta manera comparar los resultados obtenidos
anteriormente entre terminales con plataformas similares.
captura que se explic en el subcaptulo 4.1.1.1, se aplic el filtro de display o de pantalla y se
obtuvo todo el intercambio de paquetes que se realizaron durante la llamada para poder
realizar su anlisis y comprobar los pasos tericos. A continuacin en la figura 46, se puede
observar entre otras cosas que en el paquete H.225 ReleaseComplete, el terminal que origin
la llamada es el que la est liberando:
Figura 46: Informacin disponible en el Wireshark (usando NetMeeting y el servidor Beacon)
____________________________________________________________________________

84
_________________________________________________________________________
Figura 47: Traza de llamadas IP en el WireShark (usando NetMeeting y el servidor Beacon)
A continuacin se muestra una tabla 14 con las observaciones de esta captura:

Pasos de la
llamada
1) Establecimiento
de la llamada
2) Flujos de
sealizacin de
control
3) Flujo de rfagas
de media
Puertos Usados
Origen
Destino
Observaciones
1720
.- Ausencia del paquete H.225 Alerting (el servidor

Beacon H.323 no enva este paquete, se asume que el
fabricante dise su plataforma para establecer las
llamadas sin el uso del mismo). Sin embargo, esta
ausencia no obstaculiza el establecimiento de la
llamada.
correcto
1418
2626

TerminalCapabilitySet no se realiza en orden segn el
modelo terico
.- Presencia de un paquete H.245 OLCReject en
respuesta a la peticin H.245 OLC(t.120) del origen.
No aplica
No aplica
1417
.- No aplica
4) Liberacin de la
Puertos usados en pasos 1) y 2) .- El intercambio y cantidad de paquetes H.225 y
llamada
H.245 no se realiza segn el modelo terico.
Tabla 14: Observaciones de captura de trfico usando NetMeeting y servidor Beacon

____________________________________________________________________________

85
_________________________________________________________________________
Para verificar estos resultados se realizaron varias llamadas y en general todas coincidan
en las observaciones realizadas en la tabla 14. Obviamente los puertos usados variaban, pero
siempre dentro del rango.
En este caso, el paso correspondiente al flujo de rfagas de media no aplica porque el
terminal receptor (Servidor H.323 Beacon) no tiene la capacidad de recibir y/o enviar paquetes
RTP/RTCP sino bajo ciertas condiciones, que son las que ofrece el Cliente H.323 Beacon.
4.1.1.4. CAPTURA DE TRFICO USANDO TERMINALES NETMEETING Y EL

CODEC TANDBERG 6000 MXP:
Ahora disponiendo de un codec Tandberg 6000 MXP, implementado en las salas de

videoconferencia, se procedieron a realizar capturas de llamadas usando el NetMeeting en una
PC. Debido a que existan diferencias en el intercambio de paquetes cuando un terminal u otro
finalizaba la llamada se muestran a continuacin los dos casos:
Llamada finalizada por el codec Tandberg 6000 MXP:
captura que se explic en el subcaptulo 4.1.1.1, se aplic el filtro de display y se obtuvo todo
el intercambio de paquetes que se realizaron durante la llamada para poder realizar su anlisis
y comprobar los pasos tericos. A continuacin la figura 48, en la que se puede observar entre
otras cosas el paquete H.245 RoundTripDelayRequest, el cual es un comando que ejecuta el
codec para medir el retardo entre dos puntos terminales en el canal de control:
____________________________________________________________________________

86
_________________________________________________________________________
____________________________________________________________________________

87
_________________________________________________________________________
Figura 49: Traza de llamada IP en el WireShark (usando NetMeeting y codec Tandberg),

llamada finalizada por el codec Tandberg.
____________________________________________________________________________

88
_________________________________________________________________________
A continuacin se muestra la tabla 15 con las observaciones de esta captura:
Pasos de la
llamada
Puertos Usados
Origen
Destino
1) Establecimiento
de la llamada
1706
1720
2) Flujos de
sealizacin de
control
1707
11022
3) Flujo de rfagas 49604 (Audio)

de media
49602 (Video)
2334 (Audio)
2328 (Video)
Observaciones
.- Ausencia del paquete H.225 CallProceding (el
codec Tandberg MXP 6000 no enva este paquete, se
asume que el fabricante dise su plataforma para
establecer las llamadas sin el uso del mismo). Sin
embargo, esta ausencia no obstaculiza el
establecimiento de la llamada.
correcto
realiza en orden segn el modelo terico
RounfTripDelayRequest y RoundTripDelayResponse.
.- Presencia de paquetes H.245 UserInput,
MiscellaneousCommand, MiscellaneousIndication.
.- Puerto origen dentro del rango
.- Puerto destino fuera de rango (El rango de puertos
que indica el fabricante Tandberg, ver tabla 10, no
corresponden a los que se usan en la prctica). Esto
no afecta en ninguna medida el flujo de sealizacin
de control.
.- Presencia del paquete H.245 functionNotSupported
en respuesta a los paquetes H.245
FlowcontrolCommand y FlowControlIndication por
parte del codec Tandberg.
MiscellaneousCommand.
.- Presencia de paquete H.245
RounfTripDelayRequest y RoundTripDelayResponse.
.- El intercambio y cantidad de paquetes H.225 y

H.245 no se realiza segn el modelo terico.
4) Liberacin de la
Puertos usados en pasos 1) y 2) .- Presencia de paquetes H.245 CloseLogicalChannel
llamada
y CloseLogicalChannelAck
.- Puertos correctos.
Tabla 15: Observaciones de captura de trfico usando NetMeeting y codec Tandberg
Para verificar estos resultados se realizaron varias llamadas entre el NetMeeting y el codec
Tandberg 6000 MXP, en el que este ltimo finalizaba la llamada y en general todas coincidan
en las observaciones realizadas en la tabla 15. Obviamente los puertos usados variaban, pero
siempre dentro del rango, a excepcin del puerto destino en el paso 2) Flujos de sealizacin
____________________________________________________________________________

89
_________________________________________________________________________
de control. Este es un error encontrado en los manuales de usuario del codec Tandberg MXP
6000 y notificado al personal especializado en equipos Tandberg en DESCA C.A.
Llamada finalizada por el NetMeeting:
A continuacin en la figura 50, se muestra la captura de pantalla con la lista de paquetes

que se intercambiaron. En esta se puede observar entre otras cosas el paquete H.245
FlowControlCommand, el cual es un comando que ejecuta el codec o el terminal receptor para

ajustar el lmite superior de la tasa de bit del trasmisor a 3200 en el canal lgico 258:
____________________________________________________________________________

90
_________________________________________________________________________
Figura 51: Traza de llamada IP en el WireShark (Usando NetMeeting y codec Tandberg),

llamada finalizada por el NetMeeting.
En general esta captura es similar a la anterior, la nica diferencia es en el intercambio de

paquetes durante la liberacin de la llamada. En este caso, el proceso de finalizar la llamada es
iniciada por el NetMeeting y se observa que slo se trasmiten dos paquetes, uno H.245
EndSessionCommand y uno H.225 ReleaseComplete, el codec no responde con ningn

paquete. Es importante resaltar que en varias pruebas realizadas se esper un promedio de dos
minutos para darle tiempo al codec a que respondiera con un paquete H.245
EndSessionCommand siguiendo el modelo terico, y no se obtuvo respuesta; por lo tanto se

asume que la configuracin de los fabricantes Microsoft y Tandberg es distinta en la liberacin
____________________________________________________________________________

91
_________________________________________________________________________
de la llamada, sin embargo son compatibles ya que la llamadas finalizadas tanto por el codec
Tandberg MXP 6000 y por el NetMeeting fueron liberadas satisfactoriamente.
4.1.1.5. ANLISIS DE LAS CAPTURAS DE TRFICO REALIZADAS:
Para el anlisis se comparan las capturas de trfico con los distintos terminales siguiendo
los pasos de establecimiento de llamadas H.323:
1) Establecimiento de la llamada:
En las capturas con NetMeeting-NetMeeting y NetMeeting-codec Tandberg hubo ausencia
del paquete H.225 CallProceding.
En las capturas con Cliente Beacon-Servidor Beacon y NetMeeting-Servidor Beacon hubo
ausencia del paquete H.225 Alerting.
De los resultados anteriores se presume que con el uso de terminales reales como el
NetMeeting y el codec Tandberg no se implementa, o queda implcita la transmisin de
paquetes H.245 CallProceding, sin importar dnde se origine la llamada. Ocurre del mismo
modo cuando se usa terminales Beacon, pero con la ausencia del paquete H.245 Alerting (en
este caso slo el NetMeeting y el Cliente Beacon son capaces de realizar las llamadas). Sin
embargo, todas las llamadas fueron establecidas con xito, por lo tanto, el equipo inicia la
llamada de acuerdo a su programacin, siempre y cuando sea compatible con cualquier otro
dispositivo o terminal H.323 de otros fabricantes.
2) Flujo de sealizacin de control:

En ninguna de las capturas se siguen el orden de transmisin de los paquetes H.245
TerminalCapabilitySet y OpenLogicalChannel segn el modelo terico. En el caso

NetMeeting-Servidor Beacon no se abren canales lgicos porque el servidor no est diseado
para interactuar con cualquier terminal H.323, sino nicamente con el Cliente Beacon.
Los puertos usados en llamadas con el codec Tandberg no se encuentran dentro del rango
especificados por el fabricante y detallados en la tabla 10.
Sin embargo, estos imprevistos no obstaculizaron en ningn momento el flujo de
sealizacin de control.
____________________________________________________________________________

92
_________________________________________________________________________
3) Flujo de sealizacin de rfagas de media:

En todas las capturas con terminales que soportan audio y video, el intercambio de
paquetes se realiz sin ningn inconveniente. La presencia de distintos paquetes H.245 durante
este paso se deben a solicitudes de status, control, monitoreo, etc., que requieren los mismos
terminales cuando es necesario, sin embargo, el intercambio no afect la transmisin y/o
recepcin de audio y video.
4) Liberacin de la llamada:
En ninguna de las capturas el intercambio y cantidad de paquetes H.225 y H.245 se
realizaron segn el modelo terico. Este hecho no afect que las llamadas se liberaran en
forma satisfactoria, y se asume que cada fabricante (Beacon, Microsoft y Tandberg) poseen
sus propios estndares de fabricacin y configuracin que les permiten ser compatibles con
cualquier terminal H.323.
____________________________________________________________________________
Captulo 5: Conclusiones y recomendaciones

_________________________________________________________________________
CAPTULO 5: CONCLUSIONES Y RECOMENDACIONES
5.1. CONCLUSIONES:
La ejecucin de la ingeniera en detalle del diseo e implementacin del sistema de

videoconferencia sobre IP, al CNTI por parte de DESCA C.A., se llev a cabo en todos sus
objetivos de manera exitosa, an cuando el proyecto de implementacin al CNTI no ha
concluido. Se logr asimilar y documentar todas las bases tericas que refieren a la
videoconferencia sobre IP y su primera implementacin en el pas a travs de enlaces
satelitales. En este documento se detallaron los pasos, caractersticas y parmetros que se
siguieron para la ejecucin del proyecto.
Como se mencion anteriormente, es la primera vez en Venezuela que se implementa

videoconferencia a travs de sistemas satelitales, por lo tanto, no existen antecedentes
documentales ni fsicos de los cuales se pueda referenciar. DESCA C.A., como ente
involucrado en el proyecto pero sin poder de decisin o de administrar sobre cul enlace WAN
utilizar, hizo en su debido momento las observaciones y recomendaciones correspondientes al
posible funcionamiento del sistema, basndose en los tiempos de respuesta garantizados por la
empresa CVG Telecom y los requerimientos para la transmisin de audio y video sobre IP.
Con relacin a las capturas de trfico realizadas, se constat que existen ciertas variaciones
o diferencias de configuracin entre terminales H.323 de distintos fabricantes, es decir, no se
envan todos los paquetes durante el establecimiento de la llamada. Tambin se observ que
todos los terminales siguen los pasos de establecimiento de las llamadas, mas no siguen el
orden terico en el intercambio de paquetes. Con respecto a los puertos utilizados, el nico
terminal que no se encontraba dentro del rango era el codec Tandberg en el paso de Flujo de
Sealizacin de Control, lo que justifica y confirma la presuncin hecha en el subcaptulo
3.2.6, del motivo por el cual no se pudo establecer calidad de servicio utilizando listas de
acceso en los routers; sin embargo, todas las llamadas se establecieron de manera satisfactoria.
Para verificar las diferencias que existan en el intercambio de paquetes entre el modelo
____________________________________________________________________________

94
_________________________________________________________________________
terico que se us y la prctica, se contact telefnicamente a Microsoft (fabricante del
NetMeeting) y por correo electrnico a Tandberg (fabricante del codec MXP6000), pero no se
obtuvo respuestas de ninguno de ellos.
Cabe destacar que no se lograron realizar capturas de llamadas entre codecs Tandberg que
se implementaron en el proyecto del CNTI, porque para poder monitorearlo es necesario
conectar la PC a la red y tener la capacidad de ver todo lo que se transmite en la misma; el
procedimiento es conectar la PC a un switch, pero se present el inconveniente que su IOS o
sistema operativo no permite habilitar un puerto de monitoreo.
Actualmente, de acuerdo al cronograma del proyecto, se han instalado 23 nodos remotos, 3

unidades porttiles y el nodo principal en el CNTI. En este ltimo falta implementar el
Content Server y el TMS, sin embargo, stos no son indispensables para el funcionamiento del
sistema. Con respecto a los nodos remotos, falta instalar los puntos de acceso de Internet
inalmbrico.
5.2. RECOMENDACIONES:
Los resultados obtenidos en todas las pruebas realizadas, indican que los enlaces satelitales
no cumplen con los requerimientos mnimos para establecer llamadas de videoconferencia IP,
como se explica en un documento realizado para justificar el funcionamiento regular del
sistema (ver Anexo 4), las llamadas se establecen a velocidades menores a las recomendadas
para disponer de calidad de servicio, se excede en ms del doble el retardo mnimo
recomendado por el fabricante de los equipos de videoconferencia Tandberg, etc. En este
documento tambin se explican las cualidades de los equipos Tandberg para contrarrestar el
retardo, la prdida de paquetes y jitter, pero an as las llamadas no tienen buena calidad. Por
estas razones se hicieron las siguientes recomendaciones al cliente:
Deshabilitar la opcin de video de alta definicin H.264 en los codecs (habilitada por
defecto), para mejorar la capacidad del canal.
____________________________________________________________________________

95
_________________________________________________________________________
-
Buscar alternativas de enlace distintas al satelital, debido a que se comprob en la prctica

de este proyecto que no se cumple con los requerimientos mnimos para establecer
llamadas de videoconferencia de buena calidad.
Con respecto a las llamadas H.323, se recomienda profundizar el estudio de los pasos de
establecimiento de llamadas; las diferencias que existen entre terminales de distintos
fabricantes para establecer llamadas y, la diferencia entre el modelo terico de los pasos de
establecimiento de llamadas H.323 y el modo en que estos u otros terminales establecen una
sesion H.323.
Opcionalmente, en el proyecto de implementacin del sistema de videoconferencia sobre

IP al CNTI, se recomiendan hacer pruebas de captura de trfico usando switchs que permitan
habilitar puertos de monitoreo para poder ver lo que se trasnmite en la red. Del mismo
modo, probar el Cliente/Servidor Beacon H.323 en la red de videoconferencia para medir,
monitorear y calificar el desempeo de las sesiones de videoconferencia H.323 sobre enlaces
satelitales, lo que ayudara en gran medida el troubleshooting de la red.
____________________________________________________________________________
Referencias bibliogrficas
96
_________________________________________________________________________
REFERENCIAS BIBLIOGRFICAS
(2)
ATICA [2006, Junio]. Servicio de Videoconferencia, [en lnea]. Espaa. Disponible en:
http://www.um.es/atica/videocon/
(3)
TEAM SOLUTION [2006, Junio]. Video Conferencing Standards & Terminology, [en
lnea]. Reino Unido. Disponible en: http://www.teamsolutions.co.uk/tsstds.html
(4)
CISCO [2006, Julio]. Internet Protocols Documentation, [en lnea]. Disponible en:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ip.htm
(5)
Stevens, W. R., TCP/IP Illustrated, Volmen 1, Addison-Wesley, Massachusetts, pp.

33-35 (1997).
(6)
FAQS
[2006,
julio].
RFC
791,
[en
lnea].
Disponible
en:
http://www.faqs.org/rfcs/rfc791.html
(7)
CCNA 1 [2006, julio]. Conjunto de protocolos TCP/IP y direccionamiento IP, [en lnea].
Disponible en: http://www.cisco.com/web/learning/netacad/index.html
(8)
Tanenbaum, A., Redes de computadoras, Cuarta edicin, Prentice-Hall, Mxico,

pp.433-441 (2003).
(9)
Lammle, T., CCNA: Cisco Certified Neywork Associated Study Guide, Quinta
edicin, Sybex, EEUU, p. 76 (2005).
(10) TANENBAUM [2006, julio]. Computer Networks. Cuarta edicin, Sec. 5.6, p. 437. [en
lnea]. Disponible en: http://authors.phptr.com/tanenbaumcn4/
(11) Lammle, T., CCNA: Cisco Certified Neywork Associated Study Guide, Quinta
(12) RFC-ES [2006, julio]. Protocolo de control de transmisin, [en lnea]. Disponible en:
http://www.rfc-es.org/rfc/rfc0793-es.txt
(13) RFC-ES [2006, julio]. Protocolo de diagramas de usuarios, [en lnea]. Disponible en:
http://www.rfc-es.org/rfc/rfc0768-es.txt
(14) Lammle, T., CCNA: Cisco Certified Neywork Associated Study Guide, Quinta
(15) PACKETIZER [2006, agosto]. H.323 Version 6 Overview, [en lnea]. Disponible en:
http://www.packetizer.com/voip/h323/whatsnew_v6.html
____________________________________________________________________________
97
_________________________________________________________________________
(16) H323Forum [2006, agosto]. H.323: The Leading Standard in Voice over IP, [en lnea].
Disponible en: http://www.h323forum.org/papers/h.323_white_paper.pdf
(17) MICROSOFT [2006, agosto]. Chapter 11: Understanding the H.323 Standard, [en
lnea].
Disponible
en:
http://www.microsoft.com/windows/NetMeeting/Corp/reskit/Chapter11/default.asp
(18) IEC
[2006,
H.323,
agosto].
[en
lnea].
Disponible
en:
http://www.iec.org/online/tutorials/acrobat/h323.pdf
(19) Tandberg. Curso soporte a equipos Tandberg. Documento suministrado por DESCA
C.A.
(20) RADCOM
[2006,
H.323
agosto].
Tutorial,
[en
lnea].
Disponible
en:
http://www.radcom.com/LeadForm1.aspx?BoneId=675&ObjId=1&staticname1=2&FileName=h323.zip
(21) PROTOCOLS
[2006,
agosto].
H.225,
[en
lnea].
Disponible
en:
http://www.protocols.com/pbook/h323.htm#H225
(22) JAVVIN [2006, agosto]. H.225: Call Signaling and RAS in H.323 VoIP Architecture,
[en lnea]. Disponible en: http://www.javvin.com/protocolH225.html
(23) THE FREE DICTIONARY [2006, agosto]. H.225.0, [en lnea]. Disponible en:
http://encyclopedia.thefreedictionary.com/H.225
(24) CISCO [2006, agosto]. Gatekeeper-Routed Call Signaling vs Direct Endpoint Signaling,
[en lnea]. Disponible en:
http://www.cisco.com/warp/public/788/voip/understand-
gatekeepers.html#h225rassig
(25) JAVVIN [2006, agosto]. H.245: Control Protocol for Multimedia Communication, [en
lnea]. Disponible en: http://www.javvin.com/protocolH245.html
(26) Tandberg Certified Technical Expert Course. Module 4: Expressway Solutions, pp. 104110. Material Suministrado por DESCA C.A..
(27) NETWORK COMPUTING [2006, septiembre]. Network Design Manual, [en lnea].
Disponible en: http://www.networkcomputing.com/netdesign/video9.html
(28) SWITCH
[2006,
septiembre].
Videoconferencing,
[en
IP
Network
lnea].
Requirements
for
H.323
Disponible
based
en:
http://econf.switch.ch/econfportal/www/page_viewer/?id=/documentation/vconf/technic
al-descr/networkrequirements.html
____________________________________________________________________________
98
_________________________________________________________________________
(29) NETWORK COMPUTING [2006, septiembre]. Designing a Videoconferencing Solution
Manual,
[en
lnea].
Disponible
en:
http://www.networkcomputing.com/netdesign/video8.html
(30) Documento del proyecto de diseo e implantacin de una red de videoconferencia al
CNTI. Suministrado por DESCA C.A..
(31) TANDBERG [2006, Septiembre]. Tandberg and Packet Loss, [en lnea]. Disponible en:
http://www.tandberg.net/collateral/white_papers/whitepaper_TANDBERG_and_Packet_
Loss.pdf
(32) SKCOM [2006, Septiembre]. H.323 Networking, [en lnea]. Disponible en:
http://www.skccom.com/shared/Documents/polyvideo/h323networking.pdf
(33) GIGAPORT [2006, septiembre]. Secure H323 achter de firewall, [en lnea]. Disponible
en: http://www.gigaport.nl/netwerk/access/doc/h323/h3.html
(34) TANDBERG [2006, septiembre]. Tandberg 6000 MXP User Manual, [en lnea].
Disponible
en:
http://www.tandberg.net/collateral/documentation/User_Manuals/TANDBERG%206000
%20MXP%20Profile%20User%20Manual%20(F5).pdf
____________________________________________________________________________
99
Anexo1: Fundamentos tericos sobre los estndares de data, audio y video
_________________________________________________________________________
ANEXOS
ANEXO 1: Fundamentos tericos sobre los estndares de data, audio y video
Estndares de Data:
T.120
El T.120 es un estndar ITU que contiene una serie de protocolos de comunicacin y
aplicacin, desarrollados y aprobados por las industrias de computadoras internacionales y
telecomunicaciones. Con el uso de estos protocolos, los desarrolladores pueden crear
productos y servicios compatibles a tiempo real, conexiones de informacin multipunto y
conferencias. Con programas basados en T.120, mltiples usuarios pueden participar en
sesiones de conferencia sobre distintos tipos de redes y conexiones. Ms de cien proveedores
internacionales incluyendo: Apple, AT&T, British Telecom, Cisco Systems, Intel, MCI,
Microsoft, y PictureTel se han comprometido a implementar productos y servicios basados en
T.120.
Dependiendo en el tipo de producto T.120, el programa puede realizar conexiones,
transmitir y recibir informacin, y colaborar usando caractersticas compatibles en una
conferencia, como transferencia de archivos, conferencias con pizarra electrnica, etc.
El T.120 asegura que varios participantes puedan enviar y recibir informacin en
tiempo real sin ningn error en la transmisin. Esta confiabilidad se puede tener sobre muchos
tipos de conexin, incluyendo TCP/IP (Transfer Control Protocol/Internet Protocol). Para
conferencias de datos multipunto, el estndar T.120 soporta una variedad de topologas
(cascada, estrella y conexiones daisy-chain).
Una de las caractersticas ms importantes de la infraestructura del T.120 es su
interoperabilidad de productos y servicios que soportan este estndar. La interoperabilidad de
productos T.120 es medida en dos niveles: redes y aplicaciones. Los estndares T.122, T.123,
T.124 y T.125 componen el nivel de redes del T.120. Los productos y servicios que poseen
estos estndares tienen la infraestructura necesaria para:
Establecer y mantener conferencias sin dependencia de ninguna plataforma.

Manejar mltiples programas y participantes.
Enviar y recibir informacin de manera segura y precisa sobre una variedad de
conexiones de red soportadas.
Los estndares T.126 y T.127 componen el nivel de aplicacin del T.120. Estos
estndares aseguran que las pizarras electrnicas y las aplicaciones de transferencia de
archivos desarrolladas bajo el T.120 pueden interoperar sobre la mayora de plataformas y
redes, as como en conferencias multiusuarios. Sin embargo, el T.120 a dado paso al nuevo
estndar de video dual H.239.
Una conocida aplicacin que usa el T.120 es el Microsoft NetMeeting 3.0 para
Windows 2000 y Windows XP. Aunque esta aplicacin provee videoconferencia H.323,
____________________________________________________________________________
100
_________________________________________________________________________
pizarra electrnica, Chat, transferencia de archivos y aplicaciones basadas en Windows para
compartir, su mayor desventaja es el poco control sobre el anchi de banda.
Referencias:
http://www.microsoft.com/windows/NetMeeting/Corp/reskit/chapter10/default.asp
http://www.packetizer.com/conf/t120/primer/
http://www.teamsolutions.co.uk/tsshare.html
H.239
La recomendacin ITU-T H.239 es el estndar internacional para el uso, control y
etiquetado de dos canales simultneos de video en una videoconferencia. Este estndar fue
aprobado por la ITU-T en Ginebra en julio de 2003, y permite la interoperabilidad de
conferencias a mltiples proveedores de redes sobre ISDN (H.320) e IP (H.323).
El estndar H.239 est basado en una versin simplificada de las caractersticas del
People+Content patentado por Polycomm, ofrecida desde el ao 2000. Con el fin de
promover la interoperabilidad de equipos de videoconferencia de todos los fabricantes,
Polycomm ofreci a travs de la ITU-T una licencia gratis de esta tecnologa (patente de los
EEUU nmero 6.704.769) para todos los usuarios de H.239 en el mundo entero.
En la tecnologa People+Content o en espaol Gente y Contenido, el canal de
video de People transporta una vista en vivo de las personas en la conferencia, mientras que
el canal de Content muestra material de la reunin, como lminas, hojas de balance u otro
material de presentacin (bsicamente todo lo que se puede desarrollar y mostrar en una
computadora normal). Los espectadores pueden ver tanto el contenido de la presentacin
como al presentador (o las otras personas) al mismo tiempo.
Aunque algunos estndares existentes, como el H.323, siempre han soportado
mltiples canales de video, el H.239 brinda la habilidad crtica de etiquetar el rol de cada canal
en la conferencia. Con el H.239 a cada canal de video se le asigna una etiqueta que indica el
propsito del canal y cmo cada canal debe ser presentado al espectador. Las etiquetas del
H.239 son Live y Presentation.
Adems, el H.239 provee facilidad para controlar las tasas de bits de los canales de
video en los equipos de conferencia, y as manejar tokens para el rol que cumple
Presentation, de esta manera se determina automticamente las capacidades de varios de los
equipos usados en la conferencia.
Funcionamiento:
Los codecs de video en IP usan el H.245 (protocolo de control de comunicaciones
multimedia) durante el intercambio de capacidades donde se configuran las llamadas entre los
puntos terminales. En este proceso de configuracin de llamada, el H.245 establece varios
canales de video pero no les asigna ningn trabajo o responsabilidad especfica a los mimos.
____________________________________________________________________________
101
_________________________________________________________________________
Se puede usar los canales de video como una lnea de transmisin unidireccional o designar
los canales para el uso como lneas de presentacin en una conferencia multipunto.
Al conectar los terminales que soportan H.239 a la videoconferencia, cada equipo le
indica al otro su capacidad para manejar la sealizacin en H.239, qu roles de canal soporta,
y en el caso sistema H.320 sobre ISDN, qu tasas de bit de video son soportadas por el
segundo canal de video.
Durante la conferencia una serie de mensajes son intercambiados para abrir y cerrar
canales de video, controlar las tasas de bit de cada canal e indicar el rol de cada uno en la
conferencia. Estas etiquetas habilitan a los receptores para enviar a cada canal la mejor
exhibicin de cada tipo de contenido de video. Los tokens son usados para controlar cul de
los sitios en la videoconferencia est presentando en un momento dado. Si hay una mezcla de
sitios con ISDN e IP, son usados puentes y gateways para traducir los mensajes entre los
dos tipos de redes.
Referencias:
http://www.polycom.com/common/pw_cmp_updateDocKeywords/0,1687,3224,00.pdf
http://www.ihets.org/about/pubs/pdf/research/H_239_v3_2.pdf
____________________________________________________________________________
102
_________________________________________________________________________
Estndares de Audio:
G.711
El G.711 es el estndar ITU-T internacional para la codificacin de audio telefnico
(3,1kHz) en canales de 64kbps, que opera a una tasa de muestreo de 8kHz, con 8 bits por
muestreo. Este estndar usa la Modulacin por Codificacin de Pulsos o PCM (Pulse Code
Modulation, por sus siglas en ingls) para la compresin, descompresin, codificacin y
decodificacin de audio analgica, que puede ser transmitida y recibida como informacin
binaria. En telefona hay dos algoritmos definidos por el estndar para
comprimir/descomprimir: la ley (usado en Norte Amrica y Japn) y la ley A (usado en
Europa y el resto del mundo):
- Ley G.711: Comprime muestras de 14 bits PCM lineales en palabras codificadas de
8 bits PCM logartmicas.
- Ley A G.711: Comprime muestras de 13 bits PCM lineales en palabras codificadas de
8 bits PCM logartmicas.
G.722
El G.722 es un estndar ITU-T que especifica la compresin y descompresin de audio
de 7kHz a tasas de 48, 56 o 64 kbps basado en la modulacin adaptativa diferencial de la
subbanda para pulsos codificados o SB-ADPCM (Sub-Band Adaptive Differential Pulse Code
Modulation, por sus siglas en ingls), es decir, la codificacin se basa en el manejo de subbandas y slo transmite los cambios, ello permite reducir el ancho de banda necesario para
transmitir con esta calidad. Este estndar convierte seales de audio en seales digitales
uniformes, que son codificados usando 14bits a una frecuencia de muestreo de 16kHz.
G.722.1
El G.722.1 es el estndar ITU-T para la compresin de audio de 7kHz de banda ancha.
El algoritmo de compresin provee altas calidades de audio a 24kbps y 32kbps; la calidad a
32kbps es igual a la que se obtiene con el G.722 SB-ADPCM a 64 kbps. Este estndar usa un
esquema de codificacin llamada MLT (Modulated Lapped Transform, por sus siglas en
ingls); ste sustituye al estndar G.728 para bajas velocidades.
El protocolo recomendado segn la llamada:
Llamada a 128kbps: G722.1 24kbps

Llamada a 256kbps: G722.1 32kbps
Por arriba de 256kbps: G722 - 48/56 kbps
G.723.1
El G.723.1 es un estndar ITU-T para la codificacin dual de audio en el que se
comprime y descomprime seales de audio de 3.4kHz. Este estndar tiene dos tasas de
codificacin de 5,3kbps que usa el algoritmo ACELP (is Algebraic-Code-Excited Linear____________________________________________________________________________
103
_________________________________________________________________________
Prediction, por sus siglas en ingls) y 6,3kbps que usa el algoritmo MP-MLQ (Maximum
Likelihood Quantization, por sus siglas en ingls).
Sin embargo, la msica, tonos como el DTMF o fax no pueden ser transportados de
forma confiable con este codec, y algunos otros mtodos como el G.711 u otros fuera de banda
deben ser usados para transportar estas seales. El G.723.1 es usado generalmente en
aplicaciones de Voz sobre IP (VoIP) por los bajos requerimientos de ancho de banda.
G.728
El G.728 es el estndar ITU-T para la codificacin de audio de 3.4kHz para la
trasmisin sobre canales de 16kbps. La tecnologa usada es la LD-CELP (Low Delay Code
Excited Linear Prediction, por sus siglas en ingls). El retraso del codec es de 0, 625ms. La
prediccin lineal es calculada al revs con un filtro LPC de orden 50. Este estndar transmite a
bajas tasas de bit seales de modem de hasta 2400 bit/s, produciendo resultados de buena
calidad.
G.729
El G.729 es el estndar ITU-T para la codificacin de audio de 3.4kHz para la
trasmisin sobre canales de 8kbps. La tecnologa usada es la CS-ACELP (Conjugate-Structure
Algebraic-Code-Excited Linear Prediction, por sus siglas en ingls).El retraso del codec es de
15ms. Adems, este estndar ofrece un mejor uso del ancho de banda, convirtindolo en una
excelente alternativa para las aplicaciones que usaban sistemas ADPCM a 32kbps.
En su anexo A la complejidad del codec es reducida y en el anexo B soporta la
supresin de silencio y la generacin de ruido confortable (en ingls: comfort-noise).
Cuadro comparativo de los estndares de audio:
Estndar
Rango de Frecuencia
(kHz)
Ancho de banda
(kbps)
G.711
3,1
64
G.722
64
G.722.1
24/32
G.723.1
3,4
5,3/6,3
G.728
3,4
16
G.729
3,4
Referencias:
http://www.spiritdsp.com/standard_vocoders.html
http://www.gaoresearch.com/products/speechsoftware/speechsoftware.php
http://www.javvin.com/protocolG7xx.html
http://www.teamsolutions.co.uk/tsstds.html
____________________________________________________________________________
104
_________________________________________________________________________
Estndares de Video:
H.261
El H.263 (RFC 2032) es un estndar ITU de 1990 de codificacin de video, diseado
en un principio para la transmisin sobre lneas ISDN en las cuales las tasas de datos son
mltiples de 64kbps y que a veces es llamado p x 64kbps (p est en el rango de 1 a 30). Este
estndar trasporta rfagas de video usando el protocolo de trasporte en tiempo real o RTP
(Real-time transport Protocol, por sus siglas en ingls), con cualquiera de los protocolos
subyacentes que soportan RTP.
El algoritmo de codificacin es un hbrido de la prediccin entre imgenes (en ingls:
inter-picture prediction), codificacin de transformada (en ingls: transform coding) y
compensacin de movimiento (en ingls: motion compensation) con cuantizacin escalar,
escaneo en zigzag y codificacin de entropa. La tasa de datos del algoritmo de codificacin
fue diseada para operar entre 40kbps y 2Mbps. La codificacin INTRA se basa en bloques de
8x8 pxeles, cada uno codificado slo con referencia a s mismo y luego enviados
directamente al proceso de transformacin de bloques. Por otro lado la codificacin INTER de
imgenes o marcos (en ingls: frames) se codifican con respecto a otra imagen de referencia.
La prediccin entre imgenes quita redundancia temporal. La codificacin de transformada
quita la redundancia espacial usando la trasformada de un coseno discreto o DCT 8x8. Los
vectores de movimiento son usados para ayudar al codec en la compensacin de movimiento.
La cuantizacin escalar es finalmente aplicada para redondear los coeficientes de la
trasformada con lo que se obtiene la adecuada precisin, y los coeficientes de la trasformada
cuantizada son escaneados en zigzag y la entropa es codificada usando una codificacin de
longitud variable (codificacin Huffman).
Este estndar soporta la compensacin de movimiento de manera opcional en el
codificador. En esta compensacin se construye un rea especfica en la imagen anterior
(recuperada) para determinar el mejor macroblock de referencia. Los macro bloques o
macroblock son la unidad bsica de diseo.
El H.261 soporta dos resoluciones de imgenes: QCIF (Quarter Common Intermediate
Format, por sus siglas en ingls) que es de 176x144 pxeles y el CIF (Common Intermediate
Format, por sus siglas en ingls) de 352x288 pxeles.
Picture Formats Supported

Uncompressed
bitrate (Mbit/s)
Picture Luminance Luminance H.261

format
pixels
lines
support 10 frames/s
30 frames/s
Grey Colour Grey Colour

QCIF
176
144
Yes
2.0
CIF
352
288
Optional 8.1
3.0
6.1
9.1
12.2
24.3 36.5
____________________________________________________________________________
105
_________________________________________________________________________
Las rfagas de video en el estndar H.261 son una secuencia de imgenes que se
organizan en Grupo de Bloques o GOB (Group of Blocks, por sus siglas en ingls). Cada GOB
contiene 3 lneas de 11 macro bloques o MB. Cada MB transporta informacin en grupos de
16x16 pxeles: la informacin de luminancia se especifica para 4 bloques de 8x8 pxeles,
mientras que la informacin de crominancia est dada por dos componentes de color rojo y
azul, a una resolucin de 8x8 pxeles.
El multiplexor del vdeo estructura los datos comprimidos en una rfaga de bits
jerrquica que pueda ser interpretado universalmente. Esta jerarqua se define en los siguientes
niveles:
1.
2.
3.
Nivel de imagen (en ingls: Frame level): se especifica la informacin de retardo

de la imagen anterior, el formato de la imagen y otros indicadores.
Nivel Grupo de Bloques o GOB (en ingls: Group of Blocks): se especifica el
nmero de GOBs y el cuantificador por defecto a usar por los macro bloques o
MB.
Nivel de Macro bloques o MB (en ingls: Macroblocks): se especifica cul
bloque est presente y cul no ha cambiado, y opcionalmente se especifica el
cuantificador y los vectores de movimiento
La informacin del H.261 es llevada como carga til en el protocolo RTP, y sigue las
especificaciones del encabezado RTP como se muestra a continuacin:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
RTP header
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
H.261 header
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
H.261 stream ...
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
El encabezado del H.261 se define a continuacin:

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SBIT |EBIT |I|V| GOBN |
MBAP | QUANT | HMVD
| VMVD
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Los campos del encabezado del H.261 se describen a continuacin:
Bit de inicio o SBIT (Start bit, por sus siglas en ingls): 3 bits
Es el nmero de bits ms significantes que deben ser ignorados en el primer
octeto de informacin.
Bit de fin o EBIT (End bit, por sus siglas en ingls): 3 bits
____________________________________________________________________________
106
_________________________________________________________________________
Es el nmero de bits menos significantes que deben ser ignorados en el ltimo

octeto de informacin.
Informacin codificada de imagen o cuadro INTRA (campo I): 1 bit
Este campo se coloca en 1 si la rfaga contiene solo bloques de cuadros INTRA
codificados (en ingls: INTRA-frame coded blocks). Se coloca en 0 si la rfaga
puede o no contener bloques de cuadros INTRA codificados. El valor de este
bit no puede cambiar en el transcurso de la sesin RTP.
Bandera del vector de movimiento o en (campo V): 1 bit
Este campo se coloca en 0 sino se usan vectores de movimiento en esta rfaga.
Se coloca en 1 si los vectores de movimiento pueden o no ser usados en esta
rfaga. El valor de este bit no puede cambiar en el transcurso de la sesin.
Nmero de GOB (campo GOBN): 4 bits
Codifica el nmero de GOBs activos al inicio del paquete. Este campo se
coloca en 0 si el paquete comienza con un encabezado GOB.
Predictor de direccin del macro bloque o MBAP (Macroblock address predictor, por
sus siglas en ingls): 5 bits
Codifica el predictor de direccin del macro bloque (por ejemplo: el ltimo
MBA codificado en el paquete anterior). El rango del predictor es de 0-32, pero
debido a que la rfaga de bits no puede ser fragmentada entre el encabezado del
GOB y el primer MB, el predictor nunca puede ser 0 al inicio del paquete. Por
lo tanto, el rango es de 1-32, el cual es polarizado a -1 para que encaje en los
5bits. Por ejemplo, si el MBAP es 0, el valor del predictor MBA es 1. Este
campo se coloca en 0 si el paquete comienza con un encabezado GOB.
Cuantificador (campo QUANT): 5 bits
Muestra el valor cuantificado (MQUANT o GQUANT) activo, antes del inicio
de este paquete. Este campo se coloca en 0 si el paquete comienza con un
encabezado GOB.
Informacin del vector horizontal de movimiento o HMVD (en ingls: Horizontal
motion vector data): 5 bits
Representa la informacin de referencia del vector horizontal de movimiento o
MVD. Este campo se coloca en 0 si la bandera V est en 0 o si los paquetes
comienzan con un encabezado GOB, o cuando el MTYPE del ltimo MB
codificado en el paquete anterior no era MC. El HMVD es codificado como
complemento del nmero 2, y 1000 correspondiente al valor -16 es prohibido
(el rango del campo del vector de movimiento es de 15).
Informacin del vector vertical de movimiento o VMVD (en ingls: Vertical motion
vector data): 5 bits
Representa la informacin de referencia del vector vertical de movimiento o
MVD. Este campo se coloca en 0 si la bandera V est en 0 o si los paquetes
comienzan con un encabezado GOB, o cuando el MTYPE del ltimo MB
codificado en el paquete anterior no era MC. El VMVD es codificado como
complemento del nmero 2, y 1000 correspondiente al valor -16 es prohibido
(el rango del campo del vector de movimiento es de 15).
Este estndar fue el primer codificador digital de video de prctica. El diseo del H.261
fue un esfuerzo pionero y todos los subsecuentes estndares internacionales de codificacin de
____________________________________________________________________________
107
_________________________________________________________________________
video (MPEG-1, MPEG-2/H.262, H.263 y hasta el H.264) han tendido un diseo basado en el
H.261 y por lo tanto bastante parecidos.
Actualmente el estndar H.261 especifica solamente cmo se decodifica el video. El
diseo de los algoritmos de codificacin se dej a libertad de los diseadores de cdigos,
siempre y cuando cumplan con que lo obtenido a la salida del proceso de codificacin pueda
ser decodificado por cualquier decodificador hecho de acuerdo a este estndar. Los
codificadores tambin estn en la libertad de realizar cualquier pre-procesamiento a la entrada
de video, y se le permite a los decodificadores realizar cualquier post-procesamiento al video
decodificado antes de ser mostrado. Una tcnica bastante efectiva de post-procesamiento que
se ha convertido en un elemento clave en los sistemas basados en H.261 es llamado Filtrado
de Desbloqueo (en ingls: Deblocking Filtering). Este reduce la incmoda apariencia de los
artefactos con forma de bloques, causados por una parte en el diseo en la que se realiza la
compensacin de movimiento basada en bloques y la transformada espacial. Sin embargo, los
artefactos de bloqueo son probablemente un fenmeno familiar de los que han estudiado video
digital. El filtrado de desbloqueo ha sido una parte integral de los ms recientes estndares,
como el H.264 (aunque cuando se usa este estndar, se permiten post-procesos que pueden
realzar la calidad visual).
Las mejoras introducidas en estandarizaciones posteriores al diseo del H.261 han
resultado en incrementos significantes en las capacidades de compresin. Esto ha causado que
el H.261 se vuelva obsoleto, aunque todava es usado para la compatibilidad en reversa con
algunos sistemas de videoconferencia y algunos tipos de video por Internet. Sin embargo, el
H.261 permanece como el mayor avance histrico en el desarrollo del campo de la
codificacin de video.
Referencias:
http://www.javvin.com/protocolH261.html
http://www-mobile.ecs.soton.ac.uk/peter/h261/h261.html
____________________________________________________________________________
108
_________________________________________________________________________
H.263
El H.263 (RFC 2190) es un codec de video de 1995 diseado por la ITU-T como una
solucin de codificacin a bajas tasas de bit para videoconferencias y video telefona. Fue
creado en un principio para ser utilizado en sistemas basados en H.324 (Redes Telefnicas de
Servicios Telefnicos o PSTN y otras redes de circuitos conmutados de videoconferencias y
video telefona), pero se ha encontrado uso en H.323 (RTP/videoconferencia sobre IP), H.320
(videoconferencia sobre ISDN), RTSP (uso en streaming media) y SIP (conferencia en
internet).
El H.263 fue desarrollado como una mejora evolutiva basada en la experiencia que se
tena en H.261 y los estndares MPEG-1 y MPEG-2. El H.263 en su primera versin provea
mejor desempeo y recuperacin de errores en todas las tasas de bits que su antecesor H.261.
Las mejoras se fueron incrementando en las siguientes versiones: H.263v2 (tambin conocido
como H.263+ o H.263 de 1998 RFC 2429) y H.263v3 (tambin conocido como H.263++ o
H.263 de 2000).
Este estndar fue planteado para rfagas de video con bajos anchos de banda de 20kbps
a 40kbps. Como regla general, el H.263 requiere la mitad de ancho de banda para alcanzar la
misma calidad de video que el H.261. El H.263 usa el protocolo de transporte en tiempo real o
RTP para el transporte de rfagas de video.
El algoritmo de codificacin del H.263 es similar al usado por el H.261, por lo que las
tcnicas para reducir tanto la redundancia temporal como espacial, son similares. Sin embargo,
se usa la mitad de precisin de pxeles para la compensacin de movimiento, mientras que el
H.261 usa la precisin de pxeles completa y un filtro realimentado (en ingls, loop filter).
Algunas partes de la estructura jerrquica de la rfaga de datos son ahora opcionales, por lo
que el codec ahora puede ser configurado para bajas tasas de bit o mejor recuperacin de
errores. Ahora se cuentan con 4 opciones negociables para mejorar el desempeo: prediccin
anticipada (en ingls: Advance prediction), imgenes PB (en ingls: PB frames), codificacin
aritmtica basada en la sintaxis (en ingls: Syntax-based arithmetic coding) y vectores sin
restriccin del movimiento (en ingls: Unrestricted Motion Vectors). Estas opciones se pueden
usar en cualquier combinacin.
Prediccin anticipada (en ingls: Advance prediction or AP): Se pueden usar uno o
cuatro vectores de movimiento para algunos macro bloques en una imagen (en ingls:
frame). Esta caracterstica hace que la recuperacin del paquete perdido sea difcil,
porque una mayor informacin redundante tiene que ser preservada al principio de un
paquete al momento de fragmentar en el lmite del macro bloque.
- Imgenes PB (en ingls: PB frames): Se codifican dos imgenes (imagen P e imagen
B) en una rfaga de bits con los macro bloques interpolados de cada imgenes. Desde
el punto de vista de la paquetizacin, el MB de la imagen P y el MB de la imagen B
deben ser tratados como uno solo, ya que cada MB de la imagen B es codificada
basada en la correspondencia con el MB de la imagen P. Se debe proveer de un
significado para asegurar la apropiada representacin de las dos imgenes en el
correcto orden. Adems, si una parte de esta rfaga de bits se pierde se puede afectar a
ambas imgenes y probablemente ms.
____________________________________________________________________________
109
_________________________________________________________________________
Codificacin aritmtica basada en la sintaxis (en ingls: Syntax-based arithmetic

coding or SAC): Cuando se usa esta opcin, el par resultante run-value luego de la
cuantizacin de los coeficientes del la Transformada del Coseno Discreto o DCT, sern
codificados de manera distinta por los cdigos Huffman, pero la jerarqua de los macro
bloques ser preservada. Desde que las variables de contexto se sincronizan solamente
despus de cdigos de longitud fija en la rfaga de bits, cualquier fragmentacin que
empieza con cdigos de longitud variable tendr como resultado la dificultad en
decodificar en presencia de prdida de paquetes, sin llevar los valores de todas las
variables del contexto en cada encabezado de la carga til H.263.
Vectores sin restriccin del movimiento (en ingls: Unrestricted Motion Vectors): Esta
caracterstica permite un amplio rango a los vectores de movimiento para mejorar el
desempeo de la compensacin de movimiento para la codificacin INTER de
imgenes. Esta opcin tambin afecta la paquetizacin, debido a que usa un rango de
vectores de movimiento ms grande de lo normal.
Para habilitar la correcta decodificacin de los paquetes recibidos, sin tener

dependencia alguna de los paquetes anteriores, el uso de estas caractersticas opcionales se
especifica en el encabezado de la carga til del H.263.
El H.263 soporta 5 resoluciones de imgenes: CIF (en ingls: Common Intermediate
Format), QCIF (en ingls: Quarter CIF source format), SQCIF (en ingls: Sub-QCIF), 4CIF y
16CIF. Las especificaciones de cada uno de estos formatos para el H.263 se describen a
continuacin:
Picture Formats Supported
Picture Luminance Luminance H.261 H.263

format
pixels
lines
support support
Uncompressed
bitrate (Mbit/s)
10 frames/s
30 frames/s
Grey Colour Grey Colour

SQCIF 128
96
Yes
1.0
1.5
3.0
4.4
QCIF
176
144
Yes
Yes
2.0
3.0
6.1
9.1
CIF
352
288
Optional Optional 8.1
12.2
24.3
36.5
4CIF
704
576
Optional 32.4
48.7
97.3
146.0
16CIF
1408
1152
Optional 129.8 194.6
389.3 583.9
Cada imagen en el H.263 es dividida en grupos de bloques o GOB. Los GOB son
enumerados de acuerdo a un escaneo vertical de la imagen, empezando por el GOB superior y
terminando con el GOB inferior. En contraste con el GOB del H.261 que est compuesto por
tres filas de 16x16 MB para el QCIF y tres medias filas de MB del CIF, el GOB del H.263 es
dividido en macro bloques y la definicin de los MB es la misma que en el H.261. Esto
permite que se tenga una mayor flexibilidad a la hora de paquetizar.
____________________________________________________________________________
110
_________________________________________________________________________
Para cada paquete RTP, el encabezado fijo del RTP es seguido por el encabezado de
carga til del H.263, que adems es seguido por la rfaga de bits comprimidos del estndar
H.263. El tamao del encabezado de carga til del H.263 es variable dependiendo en el modo
usado. La representacin de un paquete de video RTP H.263 se muestra a continuacin:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
RTP header
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
H.263 payload header
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
H.263 bitstream
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Existen tres modos definidos (A, B y C) para el encabezado de carga til del H.263. En
el modo A, un encabezado de carga til de 4 bytes est presente antes que la rfaga de bits
comprimidas en el paquete. Esto permite la fragmentacin en los lmites de los GOB. En el
modo B, un encabezado de carga til de 8 bytes es usado y cada paquete comienza en los
lmites de los MB sin usar la opcin de la imagen-PB. Finalmente, un encabezado de carga til
de 12 bytes es definido en el modo C para soportar la fragmentacin en los lmites de los MB
para imgenes que son codificadas con la opcin de imagen-PB.
El modo de cada encabezado de carga es indicado en los campos F y P del encabezado.
Los paquetes de distintos modos pueden ser mezclados. Se requiere que todas las aplicaciones
clientes sean capaces de recibir paquetes en cualquier modo, pero la decodificacin del modo
C es opcional, debido a que la caracterstica de imagen-PB es opcional.
La estructura del encabezado modo A del H.263 se muestra a continuacin:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|P|SBIT |EBIT | SRC |I|U|S|A|R
|DBQ| TRB |
TR
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Los campos del encabezado modo A del H.263 se describen a continuacin:

F
Flag bit: indica el modo de la carga til del encabezado. Los posibles valores son:
0 - modo A.
1 - modo B o modo C dependiendo del bit P.
P
P bit: especifica los modos opcionales de imgenes PB. Los posibles valores son:
0 - normal I o imagen P.
1 imgenes PB.
Cuando F=1, P adems indica los modos de la siguiente manera:
0 - modo B.
1 - modo C.
____________________________________________________________________________
111
_________________________________________________________________________
SBIT
Bit de Inicio (en ingls: Start bit position): especifica el nmero de los bits ms significantes
que son ignorados en el primer byte de informacin.
EBIT
Bit de fin (en ingls: End bit position): especifica el nmero de los bits menos significantes
que son ignorados en el ltimo byte de informacin.
SRC
Formato de fuente (en ingles: Source format): especifica la resolucin de la imagen actual (bit
6,7 y 8 en PTYPE en la rfaga de bits comprimidos del estndard H.263).
I
Tipo de codificacin de imagen (en ingls: Picture coding type): bit 9 en PTYPE en la rfaga
de bits comprimidos del estndard H.263.
0 Codificacin INTRA.
1 - Codificacin INTER.
U
Establecido en 1 si la opcin de Vector de Movimiento sin Restriccin (bit 10 en PTYPE en la
rfaga de bits comprimidos del estndard H.263) fue establecido como 1 en el encabezado de
la imagen actual, sino su valor es 0.
S
Establecio en 1 si la opcin de Codificacin Aritmtica basada en la sintaxis (bit 11 en PTYPE
en la rfaga de bits comprimidos del estndard H.263) fue establecida como 1 en el
encabezado de la imagen actual, sino su valor es 0.
A
Establecido en 1 si la opcin de Prediccin Avanzada (bit 12 en PTYPE en la rfaga de bits
comprimidos del estndard H.263) fue establecido como 1 en el encabezado de la imagen
actual, sino su valor es 0.
R
Reservado, establecido en cero.
DBQ
Parmetro de Cuantizacin Diferencial (en ingles: Differential quantization parameter): usado
para calcular la cuantizacin de la imagen B basado en la cuantizacin de la imagen P, cuando
se usa la opcin de imgenesPB. El valor debe ser el mismo que el DBQUANT en la rfaga de
bits comprimidos del estndar H.323. Establecido en cero si la opcin de imgenes PB no est
habilitada.
TRB
Referencia temporal para la imagen B en la rfaga de bits comprimidos del estndard H.263.
Establecido en cero si la opcin de imgenes PB no est habilitada.
____________________________________________________________________________
112
_________________________________________________________________________
TR
Referencia temporal para la imagen P en la rfaga de bits comprimidos del estndard H.263.
Establecido en cero si la opcin de imgenes PB no est habilitada.
La estructura del encabezado modo B del H.263 se muestra a continuacin:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|P|SBIT |EBIT | SRC | QUANT
| GOBN
|
MBA
|R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|U|S|A| HMV1
| VMV1
| HMV2
| VMV2
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Los campos del encabezado modo B del H.263 se describen a continuacin:

F, P, SBIT, EBIT, SRC, I, U, S y A se definen igual que en el modo A.
QUANT
Valor de cuantizacin para el primer MB codificado al inicio del paquete. Establecido en cero
si el paquete comienza con un encabezado GOB.
GOBN
Nmero GOB en efecto al inicio del paquete. El nmero GOB se epsecifica diferente para
distintas resoluciones.
MBA
La direccin dentro del GOB del primer MB en el paquete, contando desde cero en el ordern
de escaneo. Por ejemplo, el tercer MB en cualquier GOB el MBA=2.
R
Reservado, establecido en cero.
HMV1, VMV1
Vectores predictores de movimiento horizontales y verticales para el primer MB en este
paquete. Cuando se usan cuatro vectores de movimiento para el MB actual, con opciones
avanzadas de prediccin, estos son los vectores predictores de movimiento del bloque nmero
1 en el MB. Cada campo de 7 bits codifica un vector predictor de movimiento en medio pxel
de resolucin de complemento 2.
HMV2, VMV2
Vectores predictores de movimiento horizontales y verticales para el tercer MB en este
paquete cuando se usan cuatro vectores de movimiento con opciones avanzadas de prediccin.
Esto se necesita debido a que el bloque nmero 3 en el MB necesita vectores predictores de
movimiento distintos de otros bloques en el MB. Estos dos campos no son usados cuando el
____________________________________________________________________________
113
_________________________________________________________________________
MB tiene un solo vector de movimiento. Cada campo de 7 bits codifica un vector predictor de
movimiento en medio pxel de resolucin de complemento 2.
La estructura del encabezado modo B del H.263 se muestra a continuacin:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|P|SBIT |EBIT | SRC | QUANT
| GOBN
|
MBA
|R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|U|S|A| HMV1
| VMV1
| HMV2
| VMV2
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR
|DBQ| TRB |
TR
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Los campos del encabezado modo C del H.263 se describen a continuacin:

F, P, SBIT, EBIT, SRC, I, U, S, A, DBQ, TRB y TR se definen igual que en el modo A.
QUANT, GOBN, MBA, HMV1, VMV1, HMV2, VNV2 se definen igual que en el modo B.
RR
Reservado, establecido en cero (19 bits).
El prximo codec desarrollado por la ITU-T (en sociedad con el MPEG) despus del
estndar H.263 es el H.264, es tambin llamado como AVC y MPEG-4 parte 10. El H.264
provee una mejora significante en capacidad. La mayora de los nuevos equipos de
videoconferencia ahora incluyen soporte para el H.264 como tambin para el H.263 y H.261.
Referencias:
http://www-mobile.ecs.soton.ac.uk/peter/h263/h263.html
http://h263.quickseek.com/
____________________________________________________________________________
114
_________________________________________________________________________
H.264
El H.264 tambin llamado MPEG-4 parte 10 (en ingls: Motion Picture Expert Group)
o AVG (en ingls: Advanced Video Coding), es un codec de video digital con el cual es
posible alcanzar una alta compresin de informacin. Dicho de otra manera, este estndar es
capaz de proveer una buena calidad de imagen con bit-rates substancialmente menores (la
mitad o menos) que los estndares previos (MPEG-2, H.263 o MPEG-4 parte 2). La
implementacin de este estndar no incrementa la complejidad de diseo y/o gastos. Adems,
es suficientemente flexible para trabajar con una variedad de redes o sistemas (radiodifusin,
telefona multimedia, videoconferencia, etc.). El protocolo de transporte del H.264 es el RTP.
Este estndar fue desarrollado conjuntamente por la ITU-T Video Coding Experts
Group (VCEG) y la ISO/IEC Moving Picture Experts Group (MPEG) como resultado de los
esfuerzos colectivos del JVT (en ingls: Joint Video Team), y se aprob en mayo de 2003. La
creacin de este estndar fue en respuesta a la necesidad creciente de tener una mayor
compresin de imgenes en movimiento en aplicaciones como el almacenamiento de media
digital, difusin de televisin, Internet streaming y comunicaciones audiovisuales en tiempo
real. Tambin fue diseado para permitir la flexibilidad en presentaciones de video codificado
en una amplia variedad de ambientes de red. El H.264 es planteado de manera genrica en el
sentido de que sirve para una amplia variedad de aplicaciones, tasas de bit, resoluciones,
calidades y servicios. Su uso permite que el video sea manipulado como datos de computadora
y sea almacenado en varios tipos de medios, a la vez de que sea transmitido y recibido sobre
los existentes y futuros canales de difusin. En el transcurso de la creacin de este estndar se
tomaron en cuenta los requerimientos de una amplia gama de aplicaciones (compresin digital
de video, Internet streaming a bajas tasa de bit, difusin de televisin de alta densidad o
HDTV, cine digital, etc.), se desarrollaron los elementos algortmicos necesarios y todo esto se
ha integrado en una sola sintaxis. Es por esto que el H.264 facilitar el intercambio de
informacin de video sobre distintas aplicaciones.
La representacin codificada que se especifica en la sintaxis, est diseada para
permitir una alta compresin con una baja degradacin de la calidad de imagen. El algoritmo
no es ordinariamente sin prdidas, ya que los valores de muestreo en la fuente tpicamente no
se mantienen durante el proceso de codificacin y decodificacin. Una cierta cantidad de
caractersticas sintcticas con procesos de decodificacin asociados se definen para alcanzar
una eficiente alta compresin, y se pueden seleccionar regiones individuales para que se
enven sin prdidas.
El algoritmo de codificacin selecciona entre la codificacin INTER e INTRA para las
regiones en forma de bloque de cada imagen. La codificacin INTER usa vectores de
movimiento para la prediccin INTER basada en bloques, y de esta manera explotar las
dependencias estadsticas temporales entre diversas imgenes. La codificacin INTRA usa
varios modelos de prediccin espacial para explotar las dependencias estadsticas espaciales en
la seal de origen dentro de una sola imagen. Los modos de prediccin INTRA y vectores de
movimiento se pueden especificar para una variedad de tamaos de bloques en la imagen. Los
residuos de seal restantes luego de la prediccin INTRA o INTER son comprimidos usando
una transformada para remover la correlacin espacial dentro de cada bloque transformado.
____________________________________________________________________________
115
_________________________________________________________________________
Estos bloques son luego cuantizados. La cuantizacin es un proceso irreversible que
tpicamente desecha la informacin visual menos importante mientras que va formando una
aproximacin cercana a las muestras originales. Finalmente, los vectores de movimiento o los
modos de prediccin INTRA son combinados con la informacin de los coeficientes de la
transformada cuantizada y luego codificadas usando los cdigos de longitud variable o la
codificacin aritmtica de contexto adaptante.
A continuacin una tabla de las caractersticas ms resaltantes del H.264 y sus
correspondientes beneficios:
Caracterstica
Compensacin de
movimiento Quartersample-accurate
Independencia del orden de

exhibicin y la referencia.
Weighted prediction
Transformada de pequeos
bloques
Transformada jerrquica de
tamaos de bloque
Transformada de palabras
cortas
Transformada inversa de
exacta coincidencia
Beneficios
El codec del H.264 usa la
compensacin de movimiento quartersample-accurate (en espaol:
precisin de un cuarto de la imagen de
muestra) como en el H.263, pero con
ciertas mejoras y complejidad
reducida.
Para obtener el mejor desempeo, el
decodificador puede elegir la va ms
eficiente de exhibicin de imgenes
para la referencia en la compensacin
de movimiento.
La seal de prediccin en la
compensacin de movimiento puede
ser weighted y offset por el
codificador, mejorando el desempeo
en escenas que contengan fades.
El H.264 se basa principalmente en la
transformada 4x4, lo cual afecta
positivamente la calidad de ciertas
escenas.
An cuando la transformada por
defecto es para bloques 4x4, el
estndar es suficientemente flexible
para transformadas de bloques de
mayor tamao, como 8x8 y 16x16,
para mejorar el desempeo en ciertas
escenas.
El H.264 reduce la complejidad
computacional, requiriendo
procesamientos de slo 16 bits.
Al contrario de la mayora de los
estndares anteriores, todos los
decodificadores que procesan rfagas
de videos usando el H.264, producirn
____________________________________________________________________________
116
_________________________________________________________________________
exactamente la misma imagen.
Codificacin de entropa
aritmtica y de contexto
adaptante
Parameter set structure
El codec H.264 usa mtodos avanzados

de codificacin de entropa, con lo que
se mejora el desempeo total.
La separacin del parameter set
structure de la informacin restante y
el manejo adecuado, hace menos
propensa la prdida de informacin.
El diseo del H.264/AVC cubre dos capas: Capa de Codificacin de Video o VCL
(Video Coding Layer, por sus siglas en ingls) que representa eficientemente el contenido del
video y la Capa de Abstraccin de la Red o NAL (Network Abstracting Layer, por sus siglas
en ingls), que le da formato a la representacin de video de la VCL y proporciona de manera
apropiada informacin de encabezado para el envo por las capas de transporte o medios de
almacenaje particulares. A continuacin se definen con ms detalle:
Capa de Codificacin de Video o VCL (Video Coding Layer, por sus siglas en ingls):
contiene la funcin de sealizacin de procesos del codec; mecanismos como
transformadas, cuantizaciones y prediccin de compensacin de movimiento; y filtros
realimentados (en ingls: loop filters). Se usa el concepto general da la mayora de los
codecs de hoy en da, como el codificador basado en macro bloques que usa prediccin
INTER de imgenes con compensacin de movimiento y transformada codificada de la
seal residual. A la salida del codificador VCL se tiene: una rfaga de bits que contiene
la informacin de los macro bloques (nmero entero de macro bloques), y la
informacin del encabezado (contiene la direccin espacial del primer macro bloque en
el slice, el parmetro inicial de cuantizacin e informacin similar). Los macro bloques
en slices son dispuestos en orden de escaneado a menos que se especifique una
ubicacin diferente de algn macro bloque, mediante el uso del llamado Sintaxis
Flexible de Orden de los Macro bloques (en ingls: Flexible Macroblock Ordering
Syntax).
Capa de Abstraccin de la Red o NAL (Network Abstracting Layer, por sus siglas en
ingls): el codificador encapsula el slice de la salida del codificador VCL en unidades
NAL, las cuales con convenientes para la transmisin sobre redes de paquetes
conmutados o usados en ambientes de multiplexacin de paquetes.
Internamente el NAL usa unidades NAL. Esta unidad consiste en un encabezado de un

byte y el arreglo de un byte de carga til. El encabezado indica el tipo de unidad NAL, la
presencia (potencial) de bits de error o violaciones en la sintaxis de la carga til de la unidad
NAL e informacin correspondiente a la relativa importancia de dicha unidad en el proceso de
decodificacin. Las especificaciones de la carga til del RTP son diseadas para no tener en
cuenta el arreglo de bits en la carga til de la unidad NAL.
____________________________________________________________________________
117
_________________________________________________________________________
Una de la principales propiedades del H.264 es el completo desacople del tiempo de
transmisin, el tiempo de decodificado y el muestreo o el tiempo de presentacin de los slices
e imgenes. El proceso de decodificacin especificado en el H.264 no toma en cuenta el
tiempo y la sintaxis no lleva informacin, como las del nmero de imgenes o cuadros
saltados (el cual es comn en la forma de referencia temporal en estndares de compresin de
video anteriores). Tambin, hay unidades NAL que afectan muchas imgenes, por lo que son
intrnsecamente sin tiempo. Por esta razn, el manejo del registro de tiempo en RTP requiere
consideraciones especiales para las unidades NAL, en las que el muestreo o la presentacin de
tiempo no esta definido o se desconoce el tiempo de transmisin.
Todas las unidades NAL consisten en un octeto, la estructura se muestra a
continuacin:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type
|
+---------------+
Los campos de la unidad NAL se describen a continuacin:

F: 1 bit
forbidden_zero_bit. La especificacin del H.264 declara el valor de 1 como una violacin
de sintaxis.
NRI: 2 bits
nal_ref_idc. El valor de 00 indica que el contenido de la unidad NAL no es usado para
reconstruir las imgenes de referencia para la prediccin de imgenes INTER. Estas unidades
NAL pueden ser desechadas sin poner en riesgo la integridad de las imgenes de regencia. Los
valores mayores de 00 indican que se requiere la decodificacin de la unidades NAL para
mantener la integridad de la referencia de la imgenes.
Type: 5 bits
nal_unit_type. Este componente especifica el tipo de carga til de la unidad NAL
(definidos en la siguiente tabla).
Tabla de los tipos de unidades NAL:
Tipo
0
1-23
24
25
26
27
28
29
30-31
Paquete
no definido
unidad NAL
STAP-A
STAP-B
MATP16
MTAP24
FU-A
FU-B
no definido
Nombre
Un solo paquete de unidad NAL por H.264
Agregacin nica del paquete
Agregacin nica del paquete
Agregacin mltiple del paquete
Agregacin mltiple del paquete
Unidad de fragmentacin
Unidad de fragmentacin
____________________________________________________________________________
118
_________________________________________________________________________
Cuando la unidad NAL es encapsulada en un paquete RTP, la estructura de la carga til
del RTP se especifica a continuacin:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC
|M|
PT
|
sequence number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
timestamp
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
synchronization source (SSRC) identifier
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
contributing source (CSRC) identifiers
|
|
....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Los campos del encabezado RTP se describen a continuacin:

- Marker bit (M): 1 bit
Establecido para el ltimo paquete de la unidad de acceso, indicado por el registro de
tiempo RTP, en concordancia con el uso normal del bit M en los formatos de video para
permitir un manejo eficiente del buffer. Para la agregacin de paquetes (STAP y MTAP), el
bit M en el encabezado RTP debe ser establecido con el valor del bit M con el cual la ltima
unidad NAL del paquete de agregacin habra sido si fuese transportado en su propio paquete
RTP. Los decodificadores pueden usar este bit como indicacin del ltimo paquete en la
unidad de acceso, pero no deben confiar en esta propiedad.
- Payload type (PT): 7 bits

La asignacin del tipo de carga til tiene que ser realizada a travs del perfil usado o
de forma dinmica.
- Sequence number (SN): 16 bits
Establecida y usada de acuerdo al RFC 3550. Para un solo NALU y el modo nointerpolado de paquetizacin, el nmero de secuencia se utiliza para determinar el orden el
decodificacin del NALU.
- Timestamp: 32 bits
El registro del tiempo RTP se establece para el muestreo de registro de tiempo del
contenido. Se debe usar una tasa de reloj de 90kHz.
EL H.264/AVC representa el mayor paso en el desarrollo en los estndares de

codificacin de video. Este tpicamente sobrepasa en un factor de dos a todos los estndares
existentes, y especialmente en comparacin con el MPEG-2, el cual es la base de los sistemas
de televisin digital en todo el mundo; se ha alcanzado una mejora con factores de 2,25-2,5.
Este avance permite el desarrollo de nuevas aplicaciones y oportunidades de negocio. Por
ejemplo, se han presentado usos de DVB-T, DVB-S2, DVD, xDSL y 3G. Sin embargo el
H.264/AVC es de dos a tres veces ms complejo que el MPEG-2 en el decodificador y de
cuatro a cinco veces ms complejo en el codificador, pero es mucho menos complejo de lo que
____________________________________________________________________________
119
_________________________________________________________________________
fue el MPEG-2 en sus inicios debido a los grandes avances en la tecnologa que se han
alcanzado desde aquel momento.
Otro hecho importante es que el H.264/AVC es un estndar pblico y abierto. Todos
los fabricantes pueden construir codificadores y decodificadores en un mercado competitivo.
Esto traer una rpida cada de precios, haciendo de esta tecnologa econmicamente de
alcance masivo. No hay dependencia en la propiedad de formatos, como lo es en Internet hoy
en da, y el cual es de extrema importancia en la comunidad de broadcast (en ingls: difusin).
Referencias:
http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=43058&ICS1=
35&ICS2=40&ICS3=&showrevision=y&scopelist=CATALOGUE
http://www.ebu.ch/en/technical/trev/trev_293-schaefer.pdf
____________________________________________________________________________
120
Anexo 2: Requerimientos de las plataformas IP y de videoconferencia
_________________________________________________________________________
ANEXO 2: Requerimientos de las plataformas IP y de videoconferencia

Plataforma IP:
A continuacin se indican los requerimientos de los equipos segn el documento licitatorio
y la solucin planteada por DESCA C.A. (para mayor informacin de los equipos, hacer clic
sobre el modelo o ver los anexos):
Requerimientos de la Plataforma IP:
Equipo
Router
Switch
Gatekeeper
Requerimientos del cliente (CNTI)

Fuente incorporada, 2FE, 4 slots, IP BASE, 64F/128D
Tarjeta de interfaz WAN, 1 Puerto Serial V35.
Cable V.35, DTE, Macho, 10 pies.
Cable de potencia 110V.
Dispositivo de administracin para routers.
256MB de memoria RAM
Sistema Operativo IOS en la versin ms reciente del
equipo.
Garanta incluida por un (1) ao.
24 puertos 10/100 Ethernet.
2 puertos Gigabit Ethernet.
2 puertos SFP para fibra y/o stacking.
Velocidad de envo mxima 6,5 Mbps.
Direcciones MAC mxima: 8000.
Norma IEEE.802.1D (Spanning Tree).
Nomra IEEE 802.1w (Rapid Spanning).
Soporte VLAN para etiquetado y basado en puerto,
en concordancia con la norma IEEE 802.1Q.
VLAN dinmica con soporte GVRP.
IGMP. Soporte Multitransmisin IP.
Soporte LACP, SNMPv1 y SNMP v2c.
Transferencias TFTP de firmware.
Soporte IP Boota/DHCP
Para ser instalado en rack de 19.
Soporte de estndares H.323 y H.225
Debe poseer al menos dos (2) puertos 10/100
(Ethernet), un (1) puerto USB y un puerto serial.
Solucin
planteada por
DESCA C.A.
Cisco 2801
Cisco Catalyst
Express WSCE500-24LC
Gatekeeper
Tandberg
____________________________________________________________________________
121
_________________________________________________________________________
Control de al menos 25 llamadas (escalable) y
recuperacin de registros aunque se reinicie la unidad.
Manejo de protocolos de seguridad HTTPS, SSH y
SCP, y capacidad para bloquear servicios IP.
Manejo de protocolos RS-232, Telnet, HTTP (S), SCP
y SSH.
Registro de diagnsticos.
Soporte Multizona con administracin de ancho de
banda Interzona e Intrazona.
Capacidad de asignacin de anchos de banda mximos
por sesin y ajuste automtico.
Chasis para ser instalado en rack cerrado de 19.
Dispositivo de conexin inalmbrica a la red LAN.
Estndares IEEE 802.11g, 802.3 y 802.3u y 802.11b.
Capaz de conectar equipos Greles-g a velocidades de
54 Mbps.
Acceso de Red Posibilidad de encriptamiento de todas las
Inalmbrico transmisiones inalmbricas.
(Access Point) Firmware actualizable va Internet a travs de Webbrowser.
Cisco Aironet
AP1100
Puerto 10/100 Auto-Cross Over (MDI/MDI-X).

Conector RJ-45.
Potencia de Transmisin 15dBm.
Plataforma de Videoconferencia:
Requerimientos de la Plataforma de videoconferencia:
Equipo
Equipo de
Videoconferencia
para Control
Multipunto con
capacidad para
codificar y
decodificar
seales de
videoconferencia
Requerimientos del cliente (CNTI)
Solucin
planteada por
DESCA C.A.
Capacidad para manejar diecisis (16) sesiones de

MCU Tandberg
videoconferencia IP.
Capacidad para manejar al menos ocho (8)
conferencias de audio independientes del audio de
las videoconferencias.
Soporte multiprotocolo: H.320, H.323 y SIP.
Soporte de estndares de video: H.261, H.263,
H.264.
____________________________________________________________________________
122
_________________________________________________________________________
MCU
(Multipoint
Conference
Unit).
Manejo de mltiples resoluciones de video: QSIF,

SIF, 4SIF, VGA, SVGA, XGA, PAL, NTSC.
Soporte de audio: G.711a, G711u, G.722, G.722.1,
G.723.1, G.728, G.729a.
Capacidad para manejar tasas de videoconferencia
entre 128 Kbps y 2 Mbps.
Capacidad para manejo de sesiones con distintas
velocidades de transmisin de manera simultnea.
Capacidad de administrar las videoconferencias a
travs de la Web. Debe incluir un software de
gestin.
Debe incluir al menos las siguientes interfaces: dos
(2) puertos 10/100 Ethernet y un (1) puerto serial
(para soportar protocolos del tipo H.320 y H.323
entre otros).
Soporte de los protocolos ms comunes de redes
(Ethernet, TCP/IP, DHCP, SSL, ARP, FTP, Telnet,
http, HTTPS, SNMP).
Soporte para protocolos de seguridad
encriptamiento (H.233, H.234, H.235).

Escalable: capacidad para apilar mltiples unidades
en cascada.
Equipo
CodificadorDecodificador de
Seales para
Videoconferencia
(CODEC)
Capacidad
para
manejar
sesiones
de
videoconferencia IP punto a punto y multipunto en Codec Tandberg
6000 MXP
modo MCU (al menos cinco (5) sesiones).
Capacidad para manejar al menos cinco (5)
conferencias de audio independientes del audio de
las videoconferencias.
Soporte multiprotocolo: H.320, H.323 y SIP.
Soporte de estndares de video: H.261, H.263,
H.264.
Manejo de mltiples resoluciones de video: QSIF,
SIF, 4SIF, VGA, SVGA, XGA, PAL, NTSC.
Mdulo V.35 para ser utilizado como enlace
alternativo de conexin. Debe incluir todo el
cableado necesario para ser conectado al mdulo del
proveedor de transporte de data.
Capacidad para manejar tres (3) cmaras externas.
Soporte de audio: G.711, G.722, G.722.1, G.728,
MPEG4.
____________________________________________________________________________
123
_________________________________________________________________________
Sonido estreo digital con sistema de voz satelital.
Conectores tipo RCA.
Capacidad para manejar tasas de videoconferencia
entre 128 Kbps y 2 Mbps.
Capacidad para manejo de sesiones con distintas
velocidades de transmisin de manera simultnea.
Capacidad de administrar las videoconferencias a
travs de la Web. Debe incluir un software de
gestin.
Debe incluir al menos las siguientes interfaces: un
(1) puerto 10/100 Ethernet, un (1) puerto USB y un
(1) puerto serial (para soportar protocolos del tipo
H.320 y H.323 entre otros).
Soporte de los protocolos ms utilizados de redes
(Ethernet, TCP/IP, DHCP, SSL, ARP, FTP, Telnet,
http, HTTPS, SNMP).
Soporte para protocolos de seguridad
encriptamiento (H.233, H.234, H.235).
Soporte
para
modo
de
unidireccional (Streaming).
videoconferencia
____________________________________________________________________________
124
Anexo 3: Descripcin de los equipos de red y videonferencia
_________________________________________________________________________
ANEXO 3: Descripcin de los equipos de red y videoconferencia

Router Cisco 2801
Descripcin general del fabricante:
Los routers multiservicio integrados de Cisco incorporan desde origen, el hardware de encriptacin
y aceleracin para construir VPNs (virtual private networks) incorporada. Como caractersticas
destacadas de seguridad integra funcionalidad de firewall y la funcionalidad del sistema de prevencin
de intrusin en lnea (IPS - intrusion prevention system). Todas estas funcionalidades de seguridad,
por primera vez integradas en un router, proporcionan a la red un mayor grado de proteccin como
nunca antes se haba ofertado en estos mercados. Adems, se han incorporado importantes mejoras
en cuanto a nmero de puestos telefnicos y canales de comunicaciones de voz, capacidad de
proceso DSP (Digital Signal Processor) y rendimiento de plataforma, que permiten comunicaciones IP
y de voz asequibles para clientes de cualquier tamao dentro de la plataforma desplegada para datos
y seguridad. La serie de routers Cisco 2800 dispone DSPs integrados en la plataforma para
proporcionar funciones como voz segura, gateway de voz, audio-conferencias, y transcodificacin,
combinadas con el proceso de llamadas integrado en Cisco IOS software.
Especificaciones
General
Tipo de dispositivo
Encaminador
Factor de forma
Anchura
Externo - modular - 1 U
44.5 cm
Profundidad
Altura
Peso
41.9 cm
4.4 cm
6.2 kg
Memoria
Memoria RAM
128 MB (instalados) / 384 MB (mx.)
Memoria Flash
64 MB (instalados) / 128 MB (mx.)
Conexin de redes
Tecnologa de conectividad
Cableado
Protocolo de interconexin de datos
Ethernet, Fast Ethernet
Red / Protocolo de transporte
IPSec
Protocolo de gestin remota
SNMP 3
____________________________________________________________________________
125
_________________________________________________________________________
Caractersticas
Proteccin firewall, criptografa 128 bits,

cifrado del hardware, soporte de MPLS,
soporte VLAN, filtrado de URL, cifrado de
256 bits
Expansin / Conectividad
Total ranuras de expansin (libres)
Interfaces
Alimentacin
Dispositivo de alimentacin
Voltaje necesario
Software / Requisitos del sistema
Software incluido
Parmetros de entorno
Temperatura mnima de funcionamiento
Temperatura mxima de funcionamiento
mbito de humedad de funcionamiento
2 ( 2 ) x AIM
2 ( 2 ) x HWIC
1 ( 1 ) x WIC
1 ( 1 ) x VIC
2 ( 2 ) x PVDM
Tarjeta CompactFlash
Memoria
1 x USB
1 x serial - auxiliar - RJ-45
1 x gestin - consola - RJ-45
2 x red - Ethernet 10Base-T/100Base-TX RJ-45
Fuente de alimentacin - interna
CA 120/230 V ( 50/60 Hz )
Cisco IOS IP Base
0 C
40 C
10 - 85%
Ms informacin: http://www.cisco.com/en/US/products/ps6018/index.html
____________________________________________________________________________
126
_________________________________________________________________________
Switch Cisco Catalyst Express WS-CE500-24LC
Descripcin general:
Posee 20 puertos 10/100 para la conexin de computadoras (o desktop connectivity, en
ingls) y 4 puertos 10/100 PoE (Power over Ethernet, por sus siglas en ingls) para conectar y
alimentar puntos de acceso inalmbrico, telefona IP o cmaras de circuito cerrado de televisin.
Adems, incluye 2 puertos 10/100/1000BASE-T (Gigabit Ethernet) o puertos SFP (Small Form-Factor
Pluggable, por sus siglas en ingls) para enlaces de subida o conexiones a servidor.
Especificaciones:
General
Width
44.5 cm
Depth
25.2 cm
Height
4.4 cm
Weight
3.7 kg
Device Type
Switch
Enclosure Type
External
Expansion / Connectivity
Expansion Slots Total (Free)
2 ( 2 ) x SFP (mini-GBIC)
Interfaces
20 x network - Ethernet 10Base-T/100Base-TX - RJ-45

4 x network / power - Ethernet 10Base-T/100Base-TX - RJ-45
2 x network - Ethernet 10Base-T/100Base-TX/1000Base-T RJ-45
Networking
Features
Layer 2 switching, power over Ethernet (PoE), autonegotiation, VLAN support, auto-uplink, manageable
Connectivity Technology
Wired
Data Link Protocol
Ethernet, Fast Ethernet
Compliant Standards
IEEE 802.3, IEEE 802.3U, IEEE 802.3z, IEEE 802.1Q, IEEE

802.3ab, IEEE 802.1p, IEEE 802.3af, IEEE 802.3x, IEEE
802.3ad (LACP), IEEE 802.11d, IEEE 802.1w, IEEE 802.1x
Data Transfer Rate
100 Mbps
Ports Qty
X Ethernet 10Base-T, Ethernet 100Base-TX
Remote Management Protocol
RMON, SNMP 3
Communication Mode
Half-duplex, full-duplex
Switching Protocol
Ethernet
MAC Address Table Size
8K entries
____________________________________________________________________________
127
_________________________________________________________________________
Auxiliary Network Ports
2x10/100/1000Base-T/SFP (mini-GBIC)
Routing Protocol
IGMPv2, IGMPv3
Miscellaneous
Compliant Standards
CE, FCC Class A certified, UL, TUV GS, CISPR 22 Class A,

GOST, cUL, NOM, IEC 60950, EN55024, EN55022 Class A, UL
60950, CSA 22.2 No. 60950, CB, FCC Part 15, MIC
MTBF
282,705 hour(s)
Power
Power Device
Power supply - internal
Voltage Required
AC 120/230 V ( 50/60 Hz )
Power Consumption Operational
45 Watt
Environmental Parameters
Min Operating Temperature
0 C
Max Operating Temperature
45 C
Humidity Range Operating
10 - 85%
Ms informacin:
http://www.cisco.com/en/US/products/ps6545/products_data_sheet0900aecd80322aeb.html
____________________________________________________________________________
128
_________________________________________________________________________
Gatekeeper Tandberg
Descripcin general:
El Gatekeeper de TANDBERG es un controlador de acceso de alto desempeo. Confiable,
seguro y fcil de usar, est diseado para complementar las soluciones de infraestructura de
TANDBERG.
Especificaciones:
Scalable from 25 to 200 concurrent calls
Uses only solid state memory for high reliability
PERFORMANCE
Up to 100 neighboring zones and up to 1000 devices and 100 services
FEATURES
Allows URI dialing for massive scalability
HTTPS, SSH, and SCP for secure management
Secure appliance based architecture
Flash memor y (diskless and no hard drive)
ARCHITECTUR ITU-T H.323 v5 compliant
E
ITU-T H.225 v4 compliant
TANDBERG Expressway Technology
H.323 v5 Annex O (for DNS dialing support)
Reliability built-in
Registrations sur vive system restart
Existing calls not affected by a system restart
RELIABILITY
Fast start-up time
Gatekeeper process recycling within seconds
H.225 Alternate Gatekeeper Support
Secure Management with HTTPS, SSH, and SCP
- Secure File Transfer
- Inactivity Timeout
Can lock-down IP ser vices
SECURITY
Authentication required on HTTP(S), Telnet, SSH, SCP, and serial port
MANAGEMENT
Compatible with H.235 v2 and v3 enabled H.323 devices

H.235 Authentication support
Supports industry standards such as RS-232, Telnet, HTTP(S), XML, SNMP, SCP,
and SSH
Embedded setup wizard on serial port for initial configuration
Management support through TANDBERG Management
Suite 9.0 or newer
Advanced management support and configuration with TANDBERG Management
Suite 11.0 or newer
Call logging and diagnostics
____________________________________________________________________________
129
_________________________________________________________________________
BANDWIDTH
MANAGEMENT
INTERFACES
DIMENSION
Suppor t for logging to a syslog ser ver

Local time zone aware
Interzone - definable call by call
- Max bandwidth per call
- Max aggregate bandwidth for all neighboring zones
Intrazone - definable call by call
- Max bandwidth per call
- Max aggregate bandwidth
Auto downspeeding if call exceeds per-call maximum
Gateway load balancing
3x LAN/Ethernet (RJ-45), 10/100 Base-TX por t
2X RS232 DB-9 (front + rear)
1x USB (rear)
426(W) x 228.6(D) x 43.5(H) mm (16.8" x 9" x 1.72")
1U rack-mount chassis
Ms informacin: http://www.tandberg.net/products/tandberg_gatekeeper.jsp
____________________________________________________________________________
130
_________________________________________________________________________
MCU
Descripcin General:
La Unidad de control multipuntos (MCU) de TANDBERG es fcilmente utilizable y escalable y
est especficamente diseada para la empresa distribuida.
Especificaciones:
MAXIMUM SYSTEM
CAPACITY
ENDPOINTS
SUPPORTED
BANDWIDTH
VIDEO STANDARDS
AUDIO STANDARDS
LIVE VIDEO
RESOLUTIONS
TRANSCODING
NETWORK
INTERFACES
Number of video conferencing endpoints: 16

Number of audio only endpoints: 16
ISDN (H.320) videoconferencing endpoints
IP (H.323) videoconferencing endpoints
Analog / IP telephony
H.320 up to 2 Mbps
H.323 up to 2 Mbps
H.261, H.263, H.263+, H.264
G.711, G.722, G.722.1, G.728
NATIVE PAL:
QCIF (176 x 144 pixels)
CIF (352 x 288 pixels)
4CIF (704 x 576 pixels)
NATIVE NTSC:
SIF (352 x 240 pixels)
4SIF (704 x 480 pixels)
NATIVE PC RESOLUTIONS:
VGA (640 x 480 pixels)
SVGA (800 x 600 pixels)
XGA (1024 x 768 pixels)
Restricted/unrestricted interfaces and bandwidths from 56 kbps - 2
Mbps in the same conference
4 x E1 / T1 G.703 (RJ-45) for ISDN PRI
1 x LAN / Ethernet (RJ-45) 10/100 Mbit
1 x LAN / Ethernet (RJ-45) 10/100 Mbit (future use)
ETHERNET / INTERNET TCP/IP, DHCP, SSL, ARP, FTP, Telnet, HTTP, HTTPS, SNMP
/ INTRANET
Embedded WEB server
CONNECTIVITY
10/100 Mbps full / half duplex (manual or auto detect selection)
OTHER SUPPORTED H.221, H.231, H.241, H.242, H.243, H.245, H.320,
____________________________________________________________________________
131
_________________________________________________________________________
STANDARDS
IP
SYSTEM
MANAGEMENT
EMBEDDED
ENCRYPTION
PHYSICAL
DIMENSIONS
H.323, BONDING (ISO 13871), Q.931

4 sites at 2 Mbps, 10 sites at 768 kbps, 16 sites at 384 kbps +
telephone calls
Total management via embedded web ser ver using HTTPS, SNMP,
Telnet and FTP
1 x RS-232 for local control and diagnostics
Conference scheduling via the TANDBERG Scheduler, Microsoft
Outlook or IBM Lotus Notes
Suppor t for the TANDBERG Management Suite
Standards based on ISDN, IP and mixed ISDN / IP: H.233,
H.234, DES 56 bit key, AES 128 bit key
NIST-validated AES
NIST-validated DES
Automatic key generation and exchange
Mix of DES / AES possible in the same conference
Height 1.7" / 4.4 cm
Width 17.4" / 44.2 cm
Depth 12.5" / 31.8 cm
Net weight 11.3 lbs / 5.15 kg
19" rack mountable
Ms informacin: http://www.tandberg.net/products/tandberg_mcu.jsp
____________________________________________________________________________
132
_________________________________________________________________________
Codec 6000 MXP:
Descripcin general:
El codec Tandberg 6000 MXP posee dimensiones estndar para su instalacin en rack, este
codec incorpora todo el poder legendario de los sistemas de video TANDBERG 6000 MXP y es ideal
para soluciones de integracin especficas.
Especificaciones:
Join up to 6 video and 5 audio sites with optional embedded MultiSite
functionality
Best possible call for each MultiSite participant with rate matching and
transcoding
APPLICATION
FEATURES
BANDWIDTH
VIDEO STANDARDS
VIDEO INPUTS (5
INPUTS)
Powerful live presentations through one-step PC plug-in or LAN connection

View presentations and presenter simultaneously with DuoVideo and H.239
Dual Stream
TANDBERG ExpresswayTM Technology
URI Dialing
H.320 up to 2 Mbps
H.323 up to 4 Mbps point-to-point
SIP up to 4 Mbps
Up to 6 Mbps total MultiSite bandwidth
H.261, H.263, H.263+, H.263++ (Natural Video), H.264
1 x MiniDin, S-video: main camera
1 x MiniDin, S-video: auxiliar y/document camera
1 x RCA/Phono, composite: document camera/aux
1 x RCA/Phono, composite: VCR
1 x DVI-I: PC
Input: 800 x 600 (@ 60, 72, 75, 85 Hz), 1024 x 768 (@ 60, 70, 75 Hz), 1280 x
720 (HD720P) (@ 50, 60 Hz), 1280 x 1024 @ 60 Hz
LIVE VIDEO
RESOLUTIONS
Extended Display Identification Data (EDID)

NATIVE NTSC:
400p (528 x 400 pixels)
4SIF (704 x 480 pixels), Digital Clarity
Interlaced SIF (iSIF 352 x 480 pixels), Natural Video
SIF (352 x 240 pixels)
NATIVE PAL:
448p (576 x 448 pixels)
4CIF (704 x 576 pixels), Digital Clarity
Interlaced CIF (iCIF 352 x 576 pixels), Natural Video
CIF (352 x 288 pixels)
____________________________________________________________________________
133
_________________________________________________________________________
QCIF (176 x 144 pixels)
SQCIF (128 x 96 pixels) decode only
NATIVE PC RESOLUTIONS:
XGA (1024 x 768)
SVGA (800 x 600 pixels)
VGA (640 x 480 pixels)
WIDE RESOLUTIONS:
w288p (512 x 288 pixels)
w448p (768 x 448 pixels)
w576p (1024 x 576 pixels)
w720p (1280 x 720 pixels)
AUDIO STANDARDS
G.711, G.722, G.722.1, G.728, 64 bit & 128 bit MPEG4 AAC-LD
Management via HTTPS
IP Administration Password
Menu Administration Password
Dialing Access code
Streaming password
H.243 MCU Password
SECURITY FEATURES VNC password
SNMP security alerts
Disable IP ser vices
MD-5 Challenge
Network Settings protection
SIP Authentication via NTLM
SIP Authentication via Digest
6 x ISDN BRI (RJ-45), S-inter face
NETWORK
INTERFACES
1 x E1/T1 G.703 (RJ-45) for ISDN PRI or Leased E1/T1 mode: Manual or Auto
(Data Triggered)
1 x E1/T1 G.703 (RJ-45) for future usage
1 x LAN/Ethernet (RJ-45) 10/100 Mbit (LAN/DSL/cable modem)

1 x X.21/V.35/RS-449 with RS-366 dialing, RS-366 Adtran IMUX, Leased Line,
Data Triggered, and Manual
1 x USB for future usage
TCP/IP, DHCP, ARP, FTP, Telnet, HTTP, HTTPS, SOAP and XML, MD-5
ETHERNET/INTERNET Challenge
/INTRANET
SNMP Enterprise Management
CONNECTIVITY
Internal web server
Internal streaming server
H.231, H.233, H.234, H.235 v2&v3, H.239, H.241, H.243, H.281, BONDING
OTHER MAJOR
(ISO 13871), H.320, H.323, H.331
STANDARDS
RFC 3261, RFC 2237, RFC 3264, RC 3311, RFC 3550, RFC 2032, RFC 2190,
SUPPORTED
RFC 2429, RFC 3407
Length: 20"/52cm
Height: 1.8"/4.4cm
DIMENSIONS
Depth: 18"/45cm
Weight: 8.8 lbs/4 kg
19" rack-mountable codec
Ms informacin: http://www.tandberg.net/products/codec_6000_mxp.jsp
____________________________________________________________________________
134
_________________________________________________________________________
TMS (Tandberg Management Suite)
Descripcin general:
Es una aplicacin Web para los administradores, el TANDBERG Management Suite o TMS hace
ms eficiente la administracin, el mantenimiento y la programacin de una red de videoconferencia
completa.
El TMS reside en un servidor dentro de la red, pero su acceso es desde cualquier computadora
que cuente con Internet Explorer ya sea en Intranet o Internet
Interfaz de usuario intuitiva y con grficos

Informacin detallada de sistema por sistema y de videconferencias
Administracin directa de terminales e infraestructura
Soporte a proveedores mltiples
Manejo de agendas a travs de Microsoft Outlook IBM Lotus Notes
Integracin con Microsoft Live Office Communicator
Especificaciones:
MANAGEMENT
CONFERENCE CONTROL CENTER

Complete conference over view on one screen
Conference and par ticipant connection control
Conference-by-conference and system-by-system information
SYSTEM UPGRADES
Pre-scheduled or ad-hoc software updates
Release key impor t and expor t
REMOTE SYSTEM CONTROL
Initiate, extend and terminate conferences
Change video layouts
Volume control and audio mute/unmute
Microphone on/off
Edit local phone books
Send messages to systems
Detect illegal system configurations
____________________________________________________________________________
135
_________________________________________________________________________
LANGUAGE
English, Simplified Chinese and Japanese
INTEGRATED
NETWORK
MONITORING
SUPPORT
Integrates with HP OpenView, IBM Tivoli, NetCool and any SNMP network
monitoring tool
FTP audit log from TANDBERG endpoints and MCUs
ACCOUNT
MANAGEMENT,
SECURITY AND
PERMISSIONS
BACKUP
MONITORING
INTEGRATION
WITH
MICROSOFT
Flexibility to limit access to TMS features and limit access to endpoints

Definition and management of user profiles
Multiple security permissions
Single sign-on authentication of users using
Windows authentication
Capability to per form daily configuration restores, ensuring systems begin the
day with the proper configuration
Backup system settings
Restore lost settings
GRAPHICAL MONITORING
Map monitor with graphic display
Customizable background images
Graphical display of call and system status
EXCHANGE SERVER
Ability to schedule conferences, book rooms and invite participants using
Microsoft Outlook
Requires Microsoft Exchange Server 2000 or 2003
OFFICE COMMUNICATOR
Ability to launch ad-hoc and multipoint calls via Office Communicator
Requires Microsoft Live Communications Server 2005
TMS SERVER REQUIREMENTS
1 GB RAM
Pentium 2 Ghz or higher Pentium compatible CPU
Microsoft Windows 2000 or 2003 Server running the latest Ser vice Packs with
Internet Information Services
TMS CLIENT REQUIREMENTS
Internet Explorer 5.5 and above or Firefox browser 1.0.8 or higher
REQUIREMENTS SEE&SHARE SERVER REQUIREMENTS
(IF INSTALLING SEE&SHARE OPTION)
Pentium I 500 MHz
Microsoft Windows 2000, 2003 or XP operating system
256 MB RAM
20 MB of available disk space for ser vices
SEE&SHARE CLIENT REQUIREMENTS
Internet Explorer 5.5 or higher
Ms informacin: http://www.tandberg.net/products/tms.jsp
____________________________________________________________________________
136
_________________________________________________________________________
Content Server
Descripcin general:
Facilita la creacin de materiales multimedia de calidad comercial desde cualquier Terminal H.323
de videoconferencia. Obtenga acceso al contenido de video cuando lo desee, en cualquier momento y
desde cualquier PC.
Distribuye y archiva video y presentaciones en vivo de doble flujo H.239

Distribuye video en formatos Microsoft Windows Media, Apple QuickTime y RealPlayer
Editor de media incorporado, con base en la red global
Panel LCD para fcil instalacin
Compatible con expressway. Admite hasta cinco videoconferencias simultneas
Especificaciones:
SYSTEM
MANAGEMENT
AND SCHEDULING
Easy configuration using LCD panel

Total management via embedded web ser ver
One-click addition of streaming and archiving suppor t to
scheduled conferences with TANDBERG Management
Suite and TANDBERG Scheduler
Simple addition of streaming and archiving suppor t to
____________________________________________________________________________
137
_________________________________________________________________________
scheduled conferences with Microsoft Outlook or
IBM Lotus Notes
Live (unicast and multicast)
On-demand (unicast)
Native suppor t for streaming Microsoft Windows MediaTM
via an embedded Windows MediaTM ser ver
STREAMING
Suppor t for external streaming ser vers (Real Networks
Real MediaTM, Apple QuickTimeTM, Windows MediaTM)

Stream H.261, H.263, H.263+, G.711
Support for streaming bandwidths from modem speed to
LAN
QCIF (176x144 pixels)
CIF (352x288 pixels)
LIVE VIDEO
VGA (640x480)
RESOLUTIONS
SVGA (800x600)
XGA (1024x768)
AUDIO STANDARDS G.711, G.722, G.722.1
QUALITY OF
Dynamic jitter buf fering
SERVICE
Packet loss concealment
Secure management via HTTPS
Integration with Active Director y for administrative
SECURITY
user and content owner access
FEATURES
Password protected streaming content playback
Automatic password protection of ad-hoc calls
Height: 1.7" (44mm)
PHYSICAL
Width: 16.8" (426mm)
DIMENSIONS
Depth: 16.4" (419mm)
19" rack-mountable, 1U height
Ms informacin: http://www.tandberg.net/products/tandberg_content_server.jsp
____________________________________________________________________________
138
Anexo 4: Documento realizado para justificar el funcionamiento regular del sistema
_________________________________________________________________________
ANEXO 4: Documento realizado para justificar el funcionamiento regular del sistema
Retardos, prdida de paquetes y desfasaje en las seales de audio y video en el sistema de

videoconferencia implantado en el CNTI
Existen dos factores que afectan el buen desempeo de las sesiones de videoconferencia
del CNTI: el ancho de banda y el retardo punto a punto. En este documento se resumen las
cualidades de los equipos Tandberg para contrarrestar la prdida de paquetes y el retardo, as
como tambin los aspectos de asignacin de ancho de banda, el retardo punto a punto que
afectan significativamente el funcionamiento del sistema, la situacin actual y las
recomendaciones.
Cualidades de los equipos Tandberg:

Los equipos Tandberg poseen una caracterstica siempre activa llamada Recuperacin
Inteligente de Prdida de Paquetes o IPRL (Intelligent Packets Lost Recovery, por sus siglas
en ingls), la cual tiene la habilidad incrementar la robustez de la rfaga de bits transmitidos,
la imagen recibida y de reducir la tasa de la llamada si es detectada una excesiva prdida de
paquetes (1-2%). Todas estas cualidades son compatibles con los estndares ITU-T. Esta
caracterstica no reemplaza las tcnicas de calidad de servicio que se puedan emplear en las
redes IP para reservar ancho de banda o establecer precedencia en el trfico de video, sino que
en el raro caso que la calidad de servicio falle, el IPRL esta diseado para reducir el impacto
de la prdida de paquetes en el trfico de video. Adems, el IPRL es la primera tcnica de
recuperacin de paquetes basada en los algoritmos de video H.261, H.263 y H.264 [1].
El equipo Tandberg 6000 MXP con el que se trabaj dispone de varias tcnicas para la
implementacin de calidad de servicio:
-
RSVP (Resource ReSerVation Protocol, por sus siglas en ingls): es un estndar usado
por los puntos terminales para solicitar cierta calidad a la red en la cual se van a
transportar los datos de audio y video.
Servicios Diferenciales (en ingls: Differential Services): Esta tcnica consiste en usar
6 bits del byte de tipo de servicio, con lo cual se dispone de un rango de 0 a 63
parmetros configurables por el usuario para valores de control, audio y video.
____________________________________________________________________________
139
_________________________________________________________________________
-
Precedencia IP y Tipo de Servicio: la precedencia IP permite a los terminales darle

prioridades a los paquetes de audio y video, por encima o por debajo de otro trfico IP
en la misma red. El Tipo de Servico o ToS es usado por los routers para que tomen
decisiones de cmo manejar el trfico si ocurre alguna congestin.
La tcnica implementada y que mejor se ajusta para el tipo de configuracin que se

dispone en este proyecto es la precedencia IP, y adems resulta compatible con el router al
aplicarle las correctas polticas de calidad de servicio en la interfaz WAN (interfaz por la que
se envan los paquetes de audio y video).
Establecimiento del ancho de banda:

Para la asignacin del ancho de banda es necesario saber que las llamadas de
videoconferencia H.323 son divididas en rfagas de audio y video, lo que implica ocupaciones
de ancho de bandas distintos (generalmente el audio usa 48Kbps o 64Kbps y el video flucta
segn las variaciones que tenga la imagen a ser transmitida). Por ejemplo, en una llamada de
384Kbps la ocupacin aproximada del video es de 320Kbps y del audio es de 48Kbps. Sin
embargo, con la sobrecarga IP, el ancho de banda total alcanza sobrepicos de 460Kbps. Por lo
que dependiendo de las variaciones del video el ancho de banda flucta entre 384Kbps y
460Kbps, es decir, un 20% aproximadamente [2]. A continuacin la combinacin
recomendada del ancho de banda de llamadas H.323 y el ancho de banda del enlace:
-
Videollamadas de 384Kbps en enlaces de 512Kbps (esta es la recomendacin mnima

para una videoconferencia).
Para los equipos Tandberg 6000 MXP se recomienda y establece por defecto si el
administrador no lo define, que el ancho de banda de las llamadas sea de 764kbps en llamadas
H.323 [3]. Sin embargo, es posible establecer llamadas a 256kbps, 192kbps y 128kbps pero la
calidad y fluidez de la llamada no ser ptima.
____________________________________________________________________________
140
_________________________________________________________________________
Retardo punto a punto:
En consultas realizadas con el proveedor Tandberg, el retardo punto a punto para calidad
de videoconferencia se recomienda no mayor a 500ms o 0,5seg antes de que sea notable la
degradacin de la calidad (prdida de paquetes, jitter, retardos).
Situacin Actual:
-
Las llamadas se establecen a 256kbps.
Se tienen saltos punto a punto en el orden de los 1100ms.
Retardos en el audio y en el video.
Video pixelado (a causa de la prdida de paquetes y al retardo punto a punto).
Desfasaje de las seales recibidas de audio y video (se debe a que se tiene el doble del
retardo punto a punto mximo recomendado y, no se puede garantizar calidad).
Los codec Tandberg 6000 MXP muestran advertencias de deficiencias en la red (Por
ejemplo: 5% de prdida de paquetes, 200ms de jitter, etc.). A continuacin el cono
que se muestra y una breve descripcin extrada del manual:
Recomendaciones:
-
Deshabilitar la opcin de video de alta definicin H.264 (habilitada por defecto), para
ahorrar ancho de banda.
Buscar alternativas de enlace distintas al satelital, el cual est comprobado en la

prctica de este proyecto que no cumple con los requerimientos mnimos para
establecer llamadas de videoconferencia de calidad.
____________________________________________________________________________
141
_________________________________________________________________________
Referencias:
[1]
http://www.tandberg.net/collateral/white_papers/whitepaper_TANDBERG_and_Packet_Loss.
pdf
[2]
http://www.skccom.com/shared/Documents/polyvideo/h323networking.pdf
[3]
http://www.tandberg.net/collateral/documentation/User_Manuals/TANDBERG%206000%20
MXP%20Profile%20User%20Manual%20(F5).pdf
____________________________________________________________________________

Ejemplo 8 de Informe

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ejemplo 8 de Informe

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD SIMN BOLVAR

Decanato de Estudios Profesionales

Ingeniera en detalle del diseo e implantacin de una red de videoconferencia sobre IP

Sartenejas, enero de 2007

UNIVERSIDAD SIMN BOLVAR

Ingeniera en detalle del diseo e implantacin de una red de videoconferencia sobre IP

Realizado con la Asesora de

INFORME FINAL DE CURSOS EN COOPERACIN TCNICA Y DESARROLLO

UNIVERSIDAD SIMN BOLVAR

Ingeniera en detalle del diseo e implantacin de una red de videoconferencia sobre IP

INFORME FINAL DE CURSOS EN COOPERACIN TCNICA Y DESARROLLO

LISTA DE SMBOLOS Y ABREVIATURAS

CAPTULO 1: INTRODUCCIN Y OBJETIVOS

1.2. Objetivo general

1.2.1. Objetivos especficos

CAPTULO 2: FUNDAMENTOS TERICOS

2.1.1. Tipos de videoconferencia

2.2. Protocolo de internet

2.2.3. Clases De direcciones IP

2.2.4. Subredes (en ingls: subnetting)

2.2.5. Mscaras de subred

2.2.6. Mscaras de subred de longitud variable

2.3. Protocolo TCP

2.4. Protocolo UDP

2.5. Nmero de puertos TCP y UDP

2.6. Estndar de videoconferencia H.323

2.6.1. Estndar de sealizacin H.225

2.6.2. Estndar de control H.245

CAPTULO 3: VIDEOCONFERENCIA SOBRE IP

Miguel Angel Yi Rojas

3.2.1. Identificacin de la plataforma de videoconferencia

3.2.2. Identificacin de la plataforma IP

3.2.3. Topologa de los nodos y diagrama de la red

3.2.4. Inspeccin preliminar y adecuacin de las salas

3.2.5. Instalacin del nodo de prueba

3.2.6. Aplicacin de calidad de servicio y distribucin de ancho de banda

CAPTULO 4: VERIFICACIN DE LLAMADAS DE VIDEOCONFERENCIA IP

4.1.1. Captura de trfico de llamadas H.323

4.1.1.1. Captura de trfico usando terminales NetMeeting

4.1.1.2. Captura de trfico usando terminales cliente/servidor Beacon H.323

4.1.1.3. Captura de trfico usando terminales NetMeeting y el servidor Beacon H.323

CAPTULO 5: CONCLUSIONES Y RECMONEDACIONES

ANEXO 2: Requerimientos de las plataformas IP y de videoconferencia

ANEXO 3: Descripcin de los equipos de red y videoconferencia

ANEXO 4: Documento realizado para justificar el funcionamiento regular del sistema

Miguel Angel Yi Rojas

Tabla 1: Estndares incluidos en el H.320

Tabla 2: Estndares incluidos en el H.323

Tabla 3: Clases de direcciones IP

Tabla 4: Direcciones privadas

Tabla 5: Puertos que usan TCP y UDP

Tabla 6: Mensajes RAS

Tabla 7: Mensajes H.245

Tabla 8: Ubicacin de las salas de videoconferencia

Tabla 12: Observaciones de capturas de trfico usando NetMeeting

Tabla 13: Observaciones de capturas de trfico usando cliente/servidor Beacon H.323

Tabla 14: Observaciones de captura de trfico usando NetMeeting y servidor Beacon

Tabla 15: Observaciones de captura de trfico usando NetMeeting y codec Tandberg

Miguel Angel Yi Rojas

Figura 1: Relacin de protocolos

Figura 2: Formato encabezado IPv4

Figura 3: Jerarqua de las direcciones IPv4

Figura 4: Formato y rango de direcciones IP segn la clase

Figura 5: Divisin recursiva de subredes