LOTE 3

PRESCRIPCIONES TÉCNICAS QUE HAN DE REGIR LA CONTRATACIÓN DEL

SUMINISTRO, INSTALACIÓN Y CONFIGURACIÓN DE LA AMPLIACIÓN DEL

SOFTWARE PARA LA GESTIÓN, CONEXIÓN, SEGURIDAD DE LA RED,

GRABACIÓN Y STREAMING DE LA UNIDAD DE CONTROL MULTIPUNTO (MCU)

DEL SISTEMA DE VIODEOCONFERENCIA DE LA UIB

Índice

1. Objeto del contrato.

2. Ubicación del equipamiento.

3. Condiciones de prestación del servicio.

4. Equipos objeto del contracto.

1. Objeto del contrato

Suministro, instalación y configuración de la ampliación del software para la

gestión, conexión, seguridad de la red, grabación y streaming de la Unidad de

Control Multipunto (MCU) del sistema de viodeoconferencia de la UIB.

Para ello el adjudicatario realizará el suministro instalación y configuración de la

ampliación del software en cuestión. Las empresas interesadas en la presente

licitación podrán realizar una visita para elaborar una propuesta acorde a las

necesidades.

Para concertar la visita pueden dirigirse via mail a:

Ariane Cuche: ariane.cuche@uib.es

2. Ubicación del equipamiento

El software al que se refiere este pliego estará ubicado en:

- Campus de la Universitat de les Illes Balears

o Edificio Gaspar Melchor de Jovellanos, Campus UIB

3. Condiciones de prestación del servicio

La empresa adjudicataria tiene que suministrar, instalar y configurar el software

detallado en el pliego de condiciones.

La empresa adjudicataria pondrá a disposición de la UIB un número de teléfono,

una dirección de correo electrónico y una persona de contacto para coordinar el

servicio de referencia.

La UIB pondrá a disposición del adjudicatario una persona de contacto que actuará

como responsable y que será la encargada de dar el visto bueno a la recepción de

todo el equipamiento suministrado por la empresa adjudicataria.

En el campus de Palma habrá una persona responsable de la recepción del

equipamiento, la persona responsable comprobará que el material entregado se

corresponda con el detallado por la empresa adjudicataria.

El equipamiento se tiene que entregar embalado y precintado, a través de una

empresa de transporte, a portes pagados.

Lugar de recepción del equipamiento.

Campus de Palma. Edificio Gaspar Melchor de Jovellanos. Ctra. De Valldemossa, Km 7,5 07122 Palma (Illes Balears)

Horario: De 9 a 14 horas. De lunes a viernes.

4. Equipos objeto del contracto

Requerimientos para la Unidad de Control Multipunto (MCU)

1. La MCU deberá soportar el trabajo en cascada con la MCU existente, Avaya Scopia Elite 5115, mediante H323 y SIP. En caso de cascada, ésta tiene que ser totalmente transparente para el usuario, que utilizará un único meeting Id independientemente de la MCU a la que se haya conectado. También tiene que ser transparente al operador para su establecimiento (esta cascada deberá ser automática) y para la operación de la videoconferencia, ya que deberá haber una única ventana de Control de conferencias para la gestión de todos los usuarios, independientemente de la MCU a la que estén conectados.

2. La MCU deberá soportar las llamadas de vídeo, basadas en estándares H.323 y SIP, simultáneamente en la misma conferencia, en todas las resoluciones, bitrates, diseños de pantalla y niveles de encriptación compatibles.

3. La MCU deberá ser capaz de aplicar valores de QoS (Calidad de Servicio) de IP a los paquetes que entran en la red IP. Se deben implementar valores separados de QoS de IP en la MCU para cada tipo de transmisión.

4. La MCU deberá soportar el protocolo de tiempo de red (NTP) para sincronizar el tiempo de MCU con una fuente de tiempo de red.

5. La MCU deberá ser virtualizable en entorno VMWare y se proveerá mediante una OVA para su despliegue.

6. La MCU deberá permitir escalabilidad añadiendo licencias para crecer en capacidad.

7. Se requiere que la MCU pueda escalar en una misma instancia hasta un mínimo de 20 puertos Full HD, 40 puertos 720p y 40 puertos 480p a 30 fps.

8. La capacidad requerida inicialmente para la nueva MCU será de 10 puertos Full HD, 20 puertos 720p y 40 puertos 480p a 30 fps.

9. La MCU deberá soportar WebRTC en la misma aplicación virtualizada. 10. La MCU deberá soportar capacidades de colaboración avanzadas y no

únicamente H.239 y BFCP. Dichas capacidades de colaboración avanzadas en la misma aplicación virtualizada permitirá que los usuarios tengan funcionalidades de pizarra virtual, anotaciones de múltiples participantes, Desktop remoto, permitiendo que un usuario tome el control remoto de otro PC y pueda controlar su ratón y su teclado.

11. La MCU deberá permitir un modo de trabajo que permita alta escalabilidad de puertos de audio respecto a la cantidad de puertos de vídeo. En dicho modo de trabajo, se tendrá una relación 50:1 entre puertos de audio y puertos de vídeo. Este modo de trabajo deberá permitir hasta 1000 participantes de sólo audio y colaboración para la MCU requerida de 20 puertos HD.

12. La MCU deben implementar un componente IVR (Repuesta de Voz Interactiva) y soportar un proceso por DTMF para el enrutamiento entrante de llamadas a números de ID de conferencia.

13. La IVR deberá ser única por plataforma y no únicamente a nivel de MCU, permitiendo que dicha IVR única permita unirse a la videoconferencia independientemente de que ésta se esté realizando en la MCU actual, en la nueva MCU o con participantes en ambas MCUs como resultado del trabajo en cascada.

14. La MCU deberá soportar control de conferencia a través de DTMF para el control de equipos de conferencia.

15. La MCU deberá ser capaz de mostrar un menú de vídeo superpuesto en la pantalla con las funciones de control mencionadas anteriormente e interactuar con el usuario cuando sea necesario. La activación y operación de este menú se realizará mediante la detección DTMF.

16. La MCU deberá tener un recurso dedicado a la transcodificación para cada participante. Utilizando este recurso, cada participante tendrá su propio diseño de vídeo personal ajustado a sus necesidades y será capaz de controlar y cambiar el diseño a través de DTMF y desde el control de conferencias web. La MCU mostrará el diseño seleccionado como un texto encima del propio video.

17. El diseño personal puede ser estático o dinámico según el número de participantes.

18. La MCU podrá mostrar en pantalla las indicaciones a cada participante por separado o a todos los participantes juntos. Como mínimo, las indicaciones incluirán:

a. Un participante se une o sale de la conferencia.

b. Participante sólo de audio. c. Número de participantes solamente en la conferencia de audio. d. Conferencia encriptada. e. Se está grabando la conferencia. f. La admisión a la conferencia está bloqueada. g. Nombre del diseño de vídeo seleccionado cuando el participante

cambia su diseño personal a través de DTMF. h. Indicación del momento en que uno de los participantes comienza /

deja de presentar, incluyendo su nombre. i. Indicación de audio o vídeo silenciada / no silenciada.

19. La MCU deberá soportar la traducción automática entre diferentes velocidades de bits (de 64Kbps a 12Mbps para vídeo), algoritmos de audio (G.711 A / μ Law, G.722, G.722.1, G.722.1 Anexo C / Siren 14, G.729 y AAC-LC), algoritmos de vídeo (H.263 y H.264), resoluciones de vídeo (QCIF, CIF, 4CIF, 480p, 720p y 1080p).

20. La MCU deberá admitir la selección automática de los bitrates óptimos de conexión, velocidad de fotogramas y resolución de imagen para una conexión óptima para cada equipo terminal que se une a la conferencia.

21. La MCU deberá soportar el control de cámara remoto, en modos de presencia activada por voz y continua, utilizando el control de cámara remoto H.281 sobre RTP.

22. La MCU deberá soportar la norma H.239 para enviar / recibir múltiples flujos de vídeo y contenido de presentación. El soporte H.239 no deberá suponer más puertos.

23. La MCU deberá admitir algoritmos de vídeo H.263 y H.264 para los canales de contenido de presentación (H.239 y BFCP).

24. La MCU deberá soportar canales de vídeo estándar H.264 hasta e incluyendo el nivel H.264 4.0 (1080p) según lo definido por el ITU-T.

25. La MCU deberá soportar el cifrado AES estándar H.235 y compatibilidad para mezclar niveles de cifrado dentro de la misma llamada. Soporte para cifrado de señalización y medios de comunicación TCP / UDP. La MCU deberá soportar el cifrado AES sin afectar la capacidad del puerto u otras características. La MCU deberá soportar el cifrado AES hasta los bitrates máximos de la MCU.

26. La MCU deberá soportar presentaciones de vídeo de presencia continua hasta 28 participantes mostrados simultáneamente en diseños dinámicamente modificables que pueden variar en la elección de 1 + 27, 1 + 20, 16, 1 + 12, 12, 2 + 8, 9, 1 + 8, 1 + 7, 1 + 6, 6, 1+ 5, 1 + 4, 4, 1 + 3, 3, 1 + 2, 2 submarcas de vídeo o un vídeo de pantalla completa.

27. La MCU deberá soportar la transcodificación de vídeo HD 720p y 1080p. 28. La MCU deberá soportar la presencia continua mixta HD 1080p y HD / SD.

La calidad de vídeo no deberá verse afectada por el número de participantes en la conferencia y la velocidad de fotogramas siempre deberá ser superior a 25fps.

23. La MCU deberá soportar una función de superposición de texto configurable, en la que la información del nombre, del identificador de sitio o del equipo terminal H.323 se puede visualizar en el borde del cuadrante de vídeo del equipo terminal del participante. Esta superposición de texto

deberá ser configurable a través de las herramientas de gestión de conferencias basadas en Web en términos de visibilidad.

24. La MCU deberá soportar las funciones de control maestro H.243 para la gestión de la conferencia mediante un equipo terminal.

25. La MCU deberá soportar un mecanismo automático en cascada, para el apoyo sin errores de las grandes conferencias que exceden la capacidad de puertos de una MCU individual.

26. La MCU deberá mostrar en las llamadas entrantes una lista de todas las conferencias que se ejecutan en la MCU.

27. La MCU deberá ser capaz de decodificar / codificar flujos de codificación de vídeo escalable (SVC) H.264 incluyendo Escalabilidad Temporal y Corrección de Error Directa (FEC) usando el algoritmo Reed Solomon. H.264 SVC deberá ser soportado junto con H.264 AVC para asegurar la interoperabilidad con dispositivos no SVC en la misma conferencia.

28. La MCU deberá soportar la Capa de Transporte Segura (TLS) para la señalización segura cuando se conecta a dispositivos SIP. Además, la MCU deberá soportar la transmisión Secure RTP (SRTP). Esto no deberá afectar la capacidad de puerto de la MCU ni otras características.

29. La MCU deberá poder conectar dispositivos basados en H.235 y SRTP en la misma conferencia de MCU.

Requerimientos para programación de reuniones y administración de la red.

1. Con el fin de poder controlar los recursos de videoconferencia se deberá proporcionar una aplicación Web desarrollada por el fabricante para administrar, hacer reservas de reuniones eventuales o de forma recurrente, provisón del control de una reunión en curso, llamadas punto a punto, la red, o ver incidencias. Esta aplicación deberá proveer la administración de la MCU así como el control sobre la red de videoconferencia.

2. La nueva MCU deberá poder ser gestionada por el actual sistema de gestión Avaya Scopia Management para disponer de un sistema de gestión integrado. En su defecto el sistema de gestión propuesto deberá ser capaz de gestionar la actual MCU Scopia Elite 5115 y la solución de Desktop y para smartphones/tablets desplegada actualmente, Scopia Desktop/Mobile.

3. El Sistema de gestión permitirá dotar de escalabilidad a la solución permitiendo que varias MCUs sean vistas como una MCU virtual con la suma de recursos de ambas y permitiendo que las reuniones se lleven a cabo en una MCU, en otra, o incluso con participantes en varias de ellas pero siempre de forma transparente al usuario.

4. El sistema de gestión deberá permitir la redundancia entre la MCU existente (AVAYA elite 5015) y la nueva MCU propuesta.

5. A cada usuario se le puede asignar una contraseña y / o ID de usuario para obtener acceso a las funciones que programa las conferencia a través del portal web de la aplicación. La aplicación deberá admitir múltiples niveles de privilegios de acceso de usuario.

6. El portal web de la aplicación deberá implementar inicio de sesión única.

7. La interfaz web de la solución deberá ejecutarse en cualquier dispositivo (ordenador, tabletas, teléfono móvil) y cualquier sistema operativo. No deberá basarse en Java o Flash, lo que puede causar problemas de seguridad.

8. La aplicación que programa las conferencias deberá optimizar a través de un algoritmo de asignación de recursos el uso de recursos de red incluyendo la asignación de usuarios a puertos MCU locales, la creación de llamadas en cascada automáticas y sin interrupciones y la autorización de llamadas ad hoc temporales. La aplicación deberá soportar el enrutamiento inteligente de llamadas en tiempo real basado en los mismos mecanismos. La aplicación deberá administrar inteligentemente un conjunto de recursos MCU para que aparezcan como una única MCU virtual para usuarios y sistemas externos. A través de reservas, la aplicación deberá proporcionar la disponibilidad de recursos. La aplicación deberá ser capaz de construir automáticamente y sin problemas de cascada dinámica de las MCUs, según requerimiento de la programación o en tiempo real. La aplicación deberá poder reasignar recursos automáticamente cuando una MCU se desconecta.

9. La aplicación que programa las conferencia deberá soportar algoritmo inteligente y optimizado de asignación de recursos en tiempo real para puertos MCU y reutilizar dinámicamente los puertos asignados de acuerdo con las capacidades reales del terminal.

10. La aplicación que programa las conferencia deberá proporcionar N + 1 tolerancia a fallos para la MCU. Si no se crea una conferencia en una MCU, la aplicación de programación buscará la siguiente MCU disponible para crear la conferencia de nuevo.

11. La aplicación que programa las conferencias deberá admitir un complemento de Microsoft Outlook para la programación desde Outlook (32bits o 64bits), que se instalará a nivel de escritorio, sin modificación en los sistemas de Active Directory o Exchange Server.

12. El complemento de la aplicación que programa las conferencias para Microsoft Outlook deberá tener las siguientes capacidades para el organizador de la reunión: Reservar un número específico de puertos, Configurar un pin moderador, Configurar un pin de acceso, Configurar la ubicación preferida, Configurar perfil de servicio, Permitir el streaming, la Grabación automática de reuniones, la Capacidad de llamar terminales una vez iniciado la conferencia.

13. La aplicación que programa las conferencias deberá admitir un complemento de Lotus Notes para la programación desde Lotus Notes 7.0, 8.0, 8.5 y 8.5.1. El complemento deberá instalarse a nivel de servidor, sin modificación en el Directorio de Domino.

14. La aplicación que programa las conferencias deberá admitir autorización y supervisión de llamadas punto a punto, tanto como conferencias de MCU para optimizar el uso del ancho de banda y de los recursos de red y asegurar videoconferencia de alta calidad.

15. La aplicación que programa las conferencias deberá admitir la administración, la gestión de uso de puertos y la reserva de recursos de múltiples MCU distribuidas y puertas de enlace. La aplicación que programa las conferencias deberá admitir la selección automática de puertos de la MCU y puertas de enlace basada en el prefijo de servicio, la búsqueda de

puertos más cercana, el equilibrio de uso de puertos y el enrutamiento de menor coste. La asignación de recursos deberá ser basada en reglas y automática sin intervención del usuario.

16. La aplicación que programa las conferencias deberá soportar la programación inteligente de topología de conferencia para la optimización del ancho de banda, basada en terminales y ubicaciones de dispositivos en red, ancho de banda y retraso relativo entre las ubicaciones.

17. La aplicación que programa las conferencias deberá soportar los recursos y la verificación de disponibilidad de los asistentes y las notificaciones de conflicto.

18. La aplicación que programa las conferencias deberá admitir salas de conferencias virtuales personalizadas. Una sala de conferencias virtual es un conjunto de preferencias de conferencia predefinidas que proporciona acceso con un solo número a la sala virtual. Las salas virtuales deben estar protegidas por el PIN de la conferencia y el PIN del moderador para que antes de que el moderador entre en la sala virtual los participantes se ubiquen en una sala de espera. La aplicación que programa las conferencia puede configurarse para rechazar todas las llamadas ad hoc excepto las conferencias de salas virtuales.

19. La aplicación que programa las conferencia deberá proporcionar al administrador la capacidad de limitar el número máximo de participantes por sala virtual para tener control total sobre la asignación de recursos de puertos de MCU.

20. La aplicación que programa las conferencias deberá proporcionar la capacidad de controlar y supervisar el uso del ancho de banda de la solución. La aplicación de programación podrá restringir el ancho de banda máximo permitido por salas virtuales y por usuarios. La aplicación de programación podrá restringir en un despliegue distribuido el máximo permitido ancho de banda dentro de una zona y entre zonas. La aplicación de programación proporcionará información de utilización del ancho de banda en tiempo real al administrador del sistema.

21. La aplicación que programa las conferencia deberá proporcionar una interfaz de control de conferencia MCU unificada sin perder ninguna característica independientemente de cómo se distribuyen los participantes o de qué recursos se utilizan. Las conferencias deben ser capaces de crecer sin problemas cuando más participantes se unan.

22. La aplicación que programa las conferencias deberá permitir el envío de un mensaje a todos los participantes conectados a una conferencia o a todos los participantes conectados a todas las conferencias, según el tipo de participante.

23. La aplicación que programa las conferencias deberá permitir iniciar y detener la grabación de cualquier conferencia dada.

24. La aplicación que programa las conferencia deberá soportar de forma transparente los terminales SIP, H.323 y los terminales de solo audio.

25. La aplicación que programa las conferencias deberá soportar sincronización manual o automática con varios dominios o con varios servidores de Active Directory, incluidos Microsoft Active Directory e IBM Lotus Domino.

26. La aplicación que programa las conferencias deberá admitir el inicio / fin automático de las llamadas programadas y la ampliación opcional en las llamadas.

27. La aplicación que programa las conferencia deberá soportar llamadas entrantes o invitación automática de la MCU ( llamadas salientes) a los terminales.

28. La aplicación que programa las conferencias deberá soportar llamadas directas a conferencias programadas.

29. La aplicación que programa las conferencias deberá soportar la generación de claves de acceso aleatorio para las reuniones programadas. Esta característica es obligatoria para aumentar el nivel de seguridad global de la solución y para garantizar la privacidad de las reuniones.

30. La aplicación que programa las conferencias deberá admitir notificaciones de correo electrónico para todos los participantes con información completa de llamadas, basada en la ubicación del participante y el tipo de terminal (H.323 / SIP).

31. La aplicación que programa las conferencias deberá soportar el modo orador en las conferencias donde el conferenciante ve a los estudiantes en un diseño de presencia continua y todos los estudiantes ven al conferenciante sólo en el diseño de pantalla.

32. La aplicación de conferencia deberá soportar la asistencia automática por IVR (Interactive Voice Response) en un entorno de multiconferencia, proporcionando la capacidad de unirse de forma transparente a través de la IVR a cada conferencia activa.

33. La aplicación de conferencia deberá proporcionar la capacidad de grabar una conferencia programada una vez que creada.

34. La aplicación de conferencia deberá proporcionar la capacidad de restringir o autorizar la grabación a un grupo definido de usuarios de acuerdo con políticas predefinidas.

35. La aplicación de conferencia deberá proporcionar una interfaz de usuario web intuitiva para modificar y ajustar los correos electrónicos de invitación a las reuniones.

36. La aplicación de conferencia deberá proporcionar una herramienta de gráficos y estadísticas que permita al administrador del sistema generar intuitivamente los gráficos / informes siguientes:

a. a. Gráficos de uso e informes: i. Los registros de llamadas multipunto para toda la

implementación / por zona / por MCU específica. ii. Registros de llamadas punto a punto para toda la

implementación / por zona. iii. Registros de llamadas por terminal. iv. Registros de llamadas multipunto por sala virtual específica.

b. Gráficos de utilización e informes: i. Utilización de puertos multipunto para toda la

implementación / por zona / por MCU específica. ii. Utilización de terminales.

iii. Utilización de salas virtuales. iv. Utilización del ancho de banda de red.

c. Gráficos estadísticos e informes para llamadas multipunto.

37. La aplicación de conferencia deberá poder generar una hoja de cálculo o un

archivo PDF con toda la información relacionada con los gráficos. 38. La aplicación de conferencia deberá soportar la reubicación automática

entre diferentes MCUs sin cambiar el identificador de acceso a reuniones. Esto es necesario en caso de fallo y para asegurar un servicio 24/7.

39. Deberá ser posible cambiar el ancho de banda de cualquier reunión en curso, así como mover fácilmente a los participantes de una reunión a otra usando arrastrar y soltar.

40. El componente de administración de red deberá soportar la recogida centralizada de los registros de la MCU y Gatekeeper, así como actualizaciones de versiones.

41. El componente de administración de red admite totalmente Firewall trasversal con herramientas de mantenimiento completas, como configuración y administración de usuarios, certificado de seguridad y administración de licencias, registro de trampas y alarmas y monitoreo en tiempo real.

42. Registro en el portal web de los eventos de la gestión de red para una solución de problemas rápida y eficaz.

43. El componente de administración de red deberá soportar la configuración del número de registros de dispositivos que se deben mantener en cualquier momento, así como el tamaño de esos archivos de registro.

44. Deberá existir una funcionalidad para realizar una copia de seguridad automática de los datos y la configuración del software de gestión. Deberá ser posible elegir la programación de la copia de seguridad, así como la ubicación donde almacenar los archivos de copia de seguridad.

45. El componente de administración de red deberá soportar la definición del tamaño del archivo de registro de red, así como el número de copias de seguridad que deberá mantener y el nivel de detalle de actividad que se deberá incluir en el archivo de registro

46. El componente de administración de red deberá soportar la recopilación de mensajes de captura SNMP de los sistemas de la MCU, Gatekeeper y cortafuegos.

47. Las aplicaciones de programación y administración de red deben poder reforzar las características de seguridad, incluyendo la contraseña sólidas, configuración de la caducidad de una contraseña periódica, del tiempo de inactividad de una sesión, del bloqueo de cuenta de usuario debido a la inactividad, del bloqueo de cuenta de usuario debido a múltiples fallos de inicio de sesión. Registro de eventos de seguridad y acceso de seguridad a través de HTTPS.

48. La aplicación que programa las conferencia y el componente de administración de red deben soportar una solución redundante para implementaciones de alta disponibilidad. La solución sólo se desplegará encima de dos servidores.

49. La aplicación que programa las conferencia y el componente de administración de red deben ser compatibles con VMware y pueden implementarse en un servidor particionado de VMware.

Requerimiento para el cliente de escritorio

1. La solución proveerá un portal de acceso a conferencias que permitirá la

realización de reuniones de Vídeo + Audio + Colaboración y también

reuniones sólo Audio + Colaboración.

2. Los usuarios de PC y Mac deberán ser capaces de conectarse a conferencias

sobre la nueva MCU propuesta pero también sobre la MCU existente: Avaya

Scopia Elite 5115, sin que sea necesario “cascadear” la nueva MCU con la

existente para que puedan participar en la misma reunión.

3. Los usuarios deberán poder unirse a una conferencia ya agendada o crear

una al momento desde el desktop, a través del portal web, e ingresando el

Conference ID. El acceso al portal web deberá ser posible desde la mayoría

de los navegadores (Internet Explorer, Firefox, Google Chrome or Safari).

4. La solución soportará cliente WebRTC embebido en los navegadores

cuando se conecte al portal tales como Google Chrome.

5. Cuando se realice la conexión a través de WebRTC no deberá ser requerida

ninguna descarga de software plug-in para acceder a cualquier conferencia

o recibir presentaciones. Para presentar contenidos desde un cliente

WebRTC será empleada una extensión del navegador.

6. Si el participante no dispone de navegadores con WebRTC deberá utilizar

necesariamente el cliente Desktop.

7. El cliente Desktop deberá desplegarse y administrarse de forma

centralizada. Deberá instalarse automáticamente vía un plug-in que sea

compatible para Windws (7, 8 and 10) y S.O. Mac.

8. Deberá ser posible instalar el cliente Desktop, en los ordenadores

personales de cada usuario sin necesitar derechos de Administrador.

9. Las actualizaciones del cliente Desktop deberán desplegarse de forma

automática a medida que los usuarios necesiten participar en conferencias

y contar con las nuevas funcionalidades, o cuando nuevas versiones de

software se encuentren disponibles.

10. El proveedor deberá proveer el cliente Desktop de forma gratuita e

ilimitada. No deberá haber ninguna restricción para desplegar el cliente

Desktop así como no será requerida ninguna licencia para cada cliente.

11. El administrador podrá requerir autenticación para los usuarios WebRTC o

clientes Desktop para acceder a una reunión. Deberá soportarse

autenticación Windows /Single Sign On (SSO). Si el usuario es autenticado

sobre Dominio Windows posteriomente no deberán solicitarse nuevas

autenticaciones.

12. El usuario deberá adaptar automáticamente el ancho de banda de la

llamada al inicio de cada llamada. Este cliente deberá adaptarse

dinámicamente a los cambios de ancho de banda que puedan producirse en

la red durante la llamada.

13. El cliente Desktop soportará protocolo de vídeo ITU-H.264 High Profile y el

códec de audio ITU-G.722.1. Además soportará compartición de datos por

Web basado en el protocolo ITU-H.239 interoperable con terminales de

videoconferencia de sala. La compartición de datos podrá ser de una sola

aplicación a todo el Escritorio del Presentador.

14. Los participantes Desktop y WebRTC soportarán capacidades de

colaboración, como Whiteboard, anotaciones múltiples, escritorio remoto

controlado por teclado y ratón.

15. El cliente Desktop deberá ser capaz de enviar resolución mínima de 720p y

recibirla en 1080p.

16. El cliente Desktop deberá ser capaz de enviar y recibir contenidos en HD

con resolución de 720p.

17. Cada cliente Desktop deberá tener capacidad de cambiar la disposición de

su vídeo en pantalla y elegir el número de videos mostrados sin causar

ningún impacto en los demás participantes de la videoconferencia. El

usuario Desktop podrá cambiar la posición de los participantes en la

disposición de la imagen empleando “drag and drop”.

18. La interfaz del usuario Desktop deberá proveer visión simultánea de los

participantes y la porción de la compartición de datos con el uso del

protocolo ITU-H.239 durante la conferencia. La interfaz del usuario deberá

proporcionar la vista en pantalla completa de los participantes o de la

compartición de datos H.239.

19. Deberá ser posible realizar anotaciones sobre la presentación. Estas

anotaciones deberán ser enviadas como parte del flujo de datos dentro de la

recomendación ITU-H.239 para lograr ser visible en el resto de los

dispositivos compatible con esta recomendación (software o hardware)

conectados a la reunión.

20. El cliente Desktop permitirá la posibilidad de regresar atrás las diapositivas

ya presentadas sin interrupir al presentador o cualquier otro asistente en la

conferencia. El material presentado deberá alojarse en el servidor durante

el transcurso de la presentación.

21. Los participantes Desktop y WebRTC deben incluir un componente nativo

que permita a los participantes participar mediante chat mientras dure la

reunión. Los clientes de Desktop deberán poder enviar chats de forma

pública o privada a cualquier participante conectado a la reunión. Esto

incluye Desktops y terminales de sala de cualquier marca.

22. Los participantes Desktop y WebRTC deberán proveer una lista de los

participantes unidos a la reunión, así como identificar si envían y reciben

audio o video, o recibir/transmitir datos.

23. El administrador del Desktop deberá ser capaz de aprovisionar un

directorio centralizado de los sistemas de sala. Este Directorio estará

disponible en el cliente Desktop y en la interfaz del usuario WebRTC para

facilitar el proceso de invitación de terminales.

24. El moderador a través del cliente y de la interfaz, deberá ser capaz de

activar la función MUTE de forma individual o a todos los participantes que

no sean el Presentador. También deberá poder desconectar participantes,

bloquear la conferencia para evitar nuevas incorporaciones y finalmente,

poder desconectar la reunión.

25. El Moderador de la conferencia deberá ser capaz de realizar movimientos,

acercamientos y alejamientos de la cámara de cualquier terminal reunido a

través de la función FECC.

26. Vía la interfaz de usuario, un moderador podrá invitar participantes

adicionales. Este Moderador deberá tener acceso al Directorio, poder elegir

entre: invitar un terminal o teléfono vía E.164, IP Address o SIP URI.

27. El Moderador de la reunión deberá ser capaz de activar el modo Lecture y

elegir qué participante será el Conferenciante. En este modo, a todos los

participantes, excepto el Conferenciante, se les cancelará el micrófono

(Mute).

28. El Conferenciante verá la disposición del vídeo de la conferencia, a los

demás asistentes a la conferencia mientras que los participantes verán

solamente al Conferenciante.

29. La solución del cliente Desktop deberá contar con la funcionalidad

Firewall/NAT trasversal embebida en la aplicación para garantizar la

conexión. Este módulo deberá proveer detección óptima para el envio de la

Media, ej: UDP, TCP, o TCP tunelizado, permitiendo a los usuarios remotos

poder unirse desde cualquier sitio en la red. El Firewall/NAT trasversal

embebido deberá funcionar en todo tipo de entorno sin requerir ninguna

configuración por parte del usuario final o cualquier tipo de producto

adicional.

30. Las conexiones hacia y desde los clientes deberán estar aseguradas

empleando protocolo SRTP o tunelizado TCP para el control de la Media y

HTTPS.

31. Los participantes Desktop y WebRTC deberán tener asegurado el acceso a la

sala empleando códigos PIN o contraseñas.

32. Un usuario de la aplicación deberá poder programar una conferencia vía

Microsoft Outlook o IBM Lotus Notes.

33. Un usuario deberá tener la posibilidad de programar una conferencia

empleando Microsoft Outlook o IBM Lotus Notes para acceder al portal Web

e ingresando el Conference ID o llamando este ID desde un sistema de sala.

34. Los participantes por Desktop o WebRTC deberán soportar el concepto de

Sala de Espera, donde los usuarios puedan conectarse al servicio, pero no

participar de forma activa hasta que el Moderador la ponga en

funcionamiento.

Requerimientos del cliente de móvil

1. El cliente de móvil deberá contar con una app para plataformas Android y

Apple.

2. El cliente de móvil deberá poder unirse a la reunión, enviar y recibir vídeo y

audio.

3. Deberá ser posible cifrar la Media (audio/video) de comunicación, así como

la señalización empleando sRTP o HTTPs.

4. La conexión a través del firewall soportará tunelizado http, así como

conexión a través de Proxy. El único puerto que deberá permanecer abierto

entre el móvil y la infraestructura es el TCP-443.

5. El cliente móvil deberá soportar conexiones 3G, 4G y conectividad a través

de WiFi.

6. Deberá tener un mecanismo que administre el ancho de banda y

acomodarlo a las posibles variaciones que se producen de forma frecuente

en los móviles.

7. La aplicación deberá proveer un mecanismo para cambiar la fuente de

cámara (ninguna, frontal o posterior).

8. El usuario de móvil podrá controlar la posición del vídeo en la pantalla.

9. Se mostrarán vistas mejoradas en la tableta para permitir ver sólo el video,

la presentación o una combinación de ambas donde se muestre una ventana

PIP redimensionable.

10. Deberá ser posible realizar en cualquier momento el cambio de formato en

la imagen de Portrait a Landscape.

11. Durante una reunión los dispositivos móviles deberán mostrar la

compartición de contenidos independientemente del dispositivo utilizado

para hacer la presentación (desktop, una sala de vídeo o cualquier

dispositivo compatible con ITU-H.239).

12. El usuario de móvil tendrá la posibilidad de regresar atrás las diapositivas

ya presentadas sin interrumpir al presentador o a cualquier otro asistente

de la conferencia. El material presentado deberá alojarse en el servidor

durante el transcurso de la presentación.

13. El cliente de móvil deberá poder visualizar la lista de participantes

conectados a la reunión.

14. Deberá ser posible invitar a cualquier otro participante a una reunión

marcando su dirección IP, su Alias e.164 o su dirección SIP URI.

15. El cliente de móvil deberá poder acceder al directorio de la compañía para

invitar fácilmente a otro terminal o usuario a una reunión en curso.

16. Para cada participante, las funciones de Moderador serán las siguientes:

Activar o bloquear el micrófono.

Activar o desactivar la cámara.

Desconectar participantes remotos.

Cambiar la plantilla del vídeo (layout).

Desplazar la ubicación de los participantes en la plantilla de video.

Visualizar estadísticas e información de la reunión.

17. El cliente de móvil deberá permitir el cambio de las siguientes propiedades

de una reunión:

Iniciar y detener una grabación.

En un momento de la reunión, poder bloquear el acceso a una reunión

para que posteriormente nadie más pueda acceder a la misma.

Requerimientos para la solución de grabación y de streaming

1. La solución de grabación y de streaming ofrecerá un portal de contenidos,

tipo YouTube, donde será posible realizar búsquedas de palabras clave en

diferentes campos para localizar la grabación deseada.

2. La solución de grabación y de streaming deberá permitir

streaming/playback desde PCs, Mac y dispositivos móviles iOS y Android.

3. La solución de grabación y streaming deberá permitir una resolución de

vídeo de 1080p.

4. El formato de las grabaciones deberá ser MP4.

5. Los códecs de audio soportados mínimos deben ser G.711 y AAC-LC.

6. Se deberá soportar como mínimo el códec de vídeo H264.

7. Para el contenido, se deberá soportar como mínimo H263 y H264.

8. Los siguientes protocolos deben estar soportados: Http Live Streaming

(HLS), Advanced Systems Format (ASF) y Microsoft Media Server (MMS).

9. La solución soportará transcoding y transrating.

10. La solución deberá soportar Multi-bitrate (MBR).

11. La solución deberá permitir grabar o hacer streaming de layouts

combinados de vídeo y colaboración. Deberá ser posible configurar layouts

de vídeo o presentación, vídeo sobre presentación y vídeo al lado de

presentación.

12. El streaming deberá soportarse en Unicast y en Multicast.

13. Se deben soportar los siguientes Media players: HTML5, Flash, Silverlight,

Windows Media Player.

14. La solución deberá permitir visualizar una grabación desde el servidor o

permitir su descarga a un fichero MP4.

15. La solución permitirá que las grabaciones sean privadas o públicas.

Inicialmente deberán ser privadas y el propietario de las mismas podrá

acceder a su área privada para hacerlas visibles en un portal de grabaciones

y eventos de webcast públicos.

16. Las grabaciones se podrán proteger por pin para asegurarse que sólo los

usuarios que lo posean puedan visualizarlas.

17. El sistema permitirá un mecanismo de seguridad adicional que sólo

permitirá a aquellos usuarios concretos que especifique el propietario, y

previa autenticación en la plataforma acceder a las grabaciones.

18. El sistema proporcionará una URL directa de acceso a grabaciones y

eventos de forma que pueda ser embebido en otras páginas web o enviar

dichos links de acceso por e-mail.

19. El sistema permitirá la programación de eventos (webcasts) cuando se

programen las videoconferencias en la plataforma.

20. Deberá ser posible lanzar la grabación desde el sistema de Control de

conferencias, desde la solución de PC y dispositivo móvil actual (Scopia) y

desde cualquier equipo de videoconferencia independientemente de la

marca y modelo.

21. La solución deberá proveer capacidad para conectar 1500 usuarios de

streaming simultáneamente.

22. El sistema permitirá 400 usuarios concurrentes conectados a la

visualización de grabaciones VoD (vídeo on demand).

23. La solución de grabación deberá optimizar el número de grabaciones

concurrentes que puede realizar en función de su resolución. Se requiere

que el sistema permita concurrentemente 5 reuniones grabadas con

resolución 1080p, 10 a 720p, 15 a 480p y 25 a 360p e inferior.

24. La solución permitirá ampliar las capacidades de grabación requeridas

actualmente x2 mediante licenciamiento.

25. La solución deberá ser “All-in-one”, con un único componente para la

grabación, el streaming y los playbacks.

26. La solución permitirá recuperar una grabación que se haya borrado por

error siempre que ésta se intente recuperar antes del tiempo definido por el

administrador para su eliminación definitiva.

27. La solución deberá soportar NAS para el almacenamiento externo de

grabaciones.

Requerimientos para Session Border Controller (SBC)

1. Un Session Border Controller (SBC) es un dispositivo de retransmisión

entre dos redes diferentes. Se puede utilizar en Firewall / NAT traversal,

traducciones de protocolos y balanceo de carga.

2. Requerirá la provisión de una solución de securización de sesiones SIP para

la conexión de terminales de videoconferencia y usuarios a conectar por

WebRTC desde fuera de la red empresarial.

3. El Session Border Controller (SBC) deberá ser virtualizable en entorno VMWare y se proveerá mediante una OVA para su despliegue.

4. Proveerá seguridad integral de troncal SIP.

5. Detendrá aplicaciones públicas basadas en SIP antes de que entren a la red

de la empresa.

6. Protegerá la operabilidad y los datos de la red contra los ataques.

7. Detendrá la suplantación, la intercepción de llamadas, los fraudes

telefónicos, el espionaje telefónico y el robo de información.

8. Soportará dar servicio a todo tipo de terminales de videoconferencia del

mercado.

9. Incluirá:

a. Seguridad UC avanzada, incluyendo protección contra fraude por

llamadas de larga distancia, Call Walking, etc.

b. Inspección profunda de paquete tanto para señalización como para multimedia.

c. DoS/DDoS (inundación, recurso colgado/transacción abierta, crash/fuzz).

d. ACL/listado blanco/negro. e. Normalización SIP – módulo troncal de integración SIP STIM. f. Control de admisión de llamadas. g. Manipulación DTMF. h. NAT trasversal (tanto de punto cercano como lejano), encubrimiento

de topología. 10. Cumplirá con RFC 5853.

Requerimientos para el firewall trasversal H323

1. El Firewall trasversal H323 y la solución de NAT trasversal permitirá la

conectividad segura entre redes empresariales y sitios remotos. Mantendrá

la seguridad y las ventajas de Firewall y NAT sobre redes de vídeo

heterogéneas.

2. Se podrá ajustar a los requisitos de topología de red y videoconferencia

existentes de la organización.

3. Se desplegará en las DMZ de la red empresarial cuando las empresas

necesitan llamadas basadas en H.323 para recorrer el cortafuegos de la red

de la empresa.

4. Permitirá una integración perfecta con los terminales de vídeo existentes y

componentes de infraestructura.

5. Utilizará el protocolo H.460 que mejora el protocolo estándar H.323 para

gestionar firewall / NAT trasversal, empleando estándares ITU-T.

6. Los equipos terminales que ya son compatibles con H.460 podrán

comunicarse directamente con el cortafuegos H323, donde el equipo

actuará como un cliente H.460 para el firewall trasversal H323 que actuará

como un servidor H.460.

7. Los equipos terminales en una red privada podrán comunicarse con los

equipos terminales ubicados en la red pública a través del servidor H323

firewall trasversal.

8. El firewall trasversal H323 ofrecerá a los terminales externos una dirección

estática al unirse a conferencias internas.

9. El Firewall trasversal H323 permitirá el firewall y NAT trasversal para una

conectividad segura entre redes empresariales y sitios remotos.

10. Funcionará con cualquier firewall, equipo terminal y gatekeeper.

11. El firewall trasversal H323 también proporcionará seguridad al separar y

restringir el tráfico IP entre las tarjetas de red externas e internas (NIC). El

NIC externo aceptará el acceso sólo desde un rango muy específico de

puertos y tipos de medios, lo que limitará significativamente los intentos

intrusivos en el sistema.

12. El firewall trasversal H323 inspeccionará el contenido del tráfico,

bloqueando contenido específico, como paquetes H.323 / RTP / RTCP no

válidos. Las rutas de cruce de firewall trasversal H323 sólo validan

paquetes basados en H.323 o paquetes basados en RTCP / RTP desde el NIC

externo al NIC interno.

13. El cortafuegos H323 admitirá Direct Public Access (DPA).

14. Soporta para la marcación URI

15. El Firewall / NAT trasversal deberá ser virtualizable en entorno VMWare y se proveerá mediante una OVA para su despliegue.

16. Tendrá la capacidad de registrar al menos 720 terminales. 17. Contará con un licenciamiento inicial de al menos 10 sesiones de vídeo, y

permitirá que esta licencia pueda incrementarse sin necesidad de modificar

el hardware original hasta 200 sesiones.

Para toda la solución garantía mínima de 2 años con los siguientes requisitos

1. Servicio centralizado de atención y gestión de incidencias, diagnósticos

remotos, actualizaciones de software, asesoramiento técnico y asistencia

para las nuevas configuraciones.

2. Gestión de los servidores virtualizados. Coordinación de las copias de seguridad de las OVA de las aplicaciones

que corren sobre los servidores virtualizados. Copias de los cambios de configuración en las máquinas virtualizadas. Recuperación de máquinas virtualizadas ante posibles caídas del

servicio. 3. Soporte técnico y servicio de atención al usuario por teléfono, correo

electrónico y videoconferencia.

4. Tiempo máximo para atender las incidencias: 1 hora.

5. Horario de atención de lunes a viernes: de 9h a 18h.

PRECIO MÁXIMO: 118.500€ ( SIN IVA).