ESPECIFICACIONES TÉCNICAS SISTEMA DE COMUNICACIONES UNIFICADAS. (SCU)

1

2

Índice de contenido GENERALIDADES.-..........................................................................................................................5 OBJETIVO.-.........................................................................................................................................5 NECESIDADES A SATISFACER.-.....................................................................................................5 BASE INSTALADA.-..........................................................................................................................6 REQUERIMIENTOS TECNICOS GENERALES .-...........................................................................7 DIMENSIONADO DEL SISTEMA.-..................................................................................................8 REQUERIMIENTOS TECNICOS OBLIGATORIOS.-......................................................................9 Procesador de Comunicaciones...................................................................................................9 Gateways...................................................................................................................................10 Servicio de Voz..........................................................................................................................12 Servicios de Video.....................................................................................................................17 Servicio de Conferencias de Video (MCU)..............................................................................20 Sala de conferencias (Meeting room) de voz............................................................................22 Mensajería Instantánea (chat)...................................................................................................22 Presencia...................................................................................................................................22 Servicios de Pre-atención, Correo de Voz.................................................................................23 Tarificación...............................................................................................................................24 Movilidad..................................................................................................................................25 Conferencia web y Colaboración..............................................................................................26 Funcionalidades para discapacidad auditiva.............................................................................26 Fax Server.................................................................................................................................27 Session Border Controller.........................................................................................................28 Terminales.................................................................................................................................29 Teléfono IP propietarios de escritorio..............................................................................30 Teléfono IP gama baja:....................................................................................................30 Teléfono IP gama baja (inalámbrico):..............................................................................30 Teléfono IP gama intermedia:..........................................................................................31 Teléfono IP gama alta (videoteléfono):............................................................................31 Equipos para salas:..........................................................................................................31 Cliente UC para PC:........................................................................................................33 Cliente UC para Teléfono Móvil:....................................................................................34 Software de Administración del SCU.......................................................................................35 Auto Provisionamiento de Terminales......................................................................................36 REQUERIMIENTOS PARA EL EQUIPAMIENTO.-.......................................................................36 Requerimientos específicos para servidores (mínimos)............................................................37 OTROS REQUERIMIENTOS OBLIGATORIOS.............................................................................38 CONDICIONES ESPECIALES.-......................................................................................................38 Definición de funcionalidades y funciones...............................................................................38 Marcas.......................................................................................................................................39 Interoperabilidad.......................................................................................................................41 Instalación.................................................................................................................................41 CAPACITACIÓN.-.............................................................................................................................42 REQUERIMIENTOS PARA LA EMPRESA PROVEEDORA Y EL FABRICANTE.-....................43 MAQUETA DE COMPATIBILIDAD, INTEGRACIÓN Y FUNCIONALIDADES BÁSICAS.-....44 CANTIDADES A COMPRAR.-........................................................................................................45 EVALUACIÓN Y COMPARACIÓN DE OFERTAS.-......................................................................46

3

4

1. GENERALIDADES.La Intendencia de Montevideo (de aquí en más I.M.) llama a interesados en proveer una plataforma tecnológica de Comunicaciones Unificadas que permita la integración de servicios de comunicaciones empresariales en tiempo real, como audio y video, con servicio no en tiempo real, como mensajería y correo de voz, además de proveer funcionalidades avanzadas como presencia, movilidad y conferencias; utilizando para ello las redes de datos IP de la IM. Se requiere un Sistema de Comunicaciones Unificadas (de aquí en más SCU) para lo cual emite las presentes especificaciones técnicas con la finalidad de evaluar las diferentes propuestas tecnológicas y seleccionar el mejor proveedor de los servicios convergentes.

2. OBJETO.La I.M. solicita la provisión, diseño, implementación, configuración, integración, puesta en marcha, soporte, garantías y capacitación de una solución "llave en mano" de un SCU basada en la tecnología IP. El adjudicatario desplegará el SCU para 750 posiciones de funcionarios (inicialmente), salas de reuniones y espacios comunes. La SCU deberá ser modular de forma que a partir de una solución inicial de telefonía IP, permita incorporar servicios de mensajería unificada (correo electrónico, correo de voz y fax), mensajería instantánea corporativa, conferencias de video, conferencias web, presencia, movilidad y colaboración.

3. NECESIDADES A SATISFACER.La solución propuesta deberá brindar todas las prestaciones de un SCU más allá de un servicio de telefonía IP. La solución deberá integrarse inicialmente con el resto de la plataforma de telefonía del Edificio Sede, permitiendo una migración eficiente a la misma para llegar a ser la única solución de telefonía de la I.M. Deberá ser escalable y en el inicio debe soportar al menos 750 internos (en sustitución del punto 2 de la sección BASE INSTALADA), pudiéndose colocar módulos de expansión o licencias que permitan aumentar sus capacidades (extensiones, líneas analógicas, troncales digitales, troncales IP, redundancia, aplicaciones y otros módulos) y llegar al menos a 4000 internos. La plataforma deberá tener capacidad de funcionar en redundancia geográfica o local en modo Activo/Activo. Además deberá indicar el máximo número de nodos que pueda 5

soportar dicha implementación. Esta solución deberá ser capaz de funcionar con un solo nodo activo soportando toda la carga. Se deberá proveer un plan detallado de migración que contemple los siguientes aspectos: - Minimizar el impacto para los usuarios del sistema. - Implementación en los tiempos y etapas requeridos por la licitación. - Integración con los subsistemas actuales de telefonía

4. BASE INSTALADA.La plataforma telefónica de la I.M. se compone actualmente de los siguientes 4 elementos: 1) Una central NEC NEAX 7400 con 1500 internos (NEC) para atender los usuarios del Edificio Sede. 2) Una plataforma Asterisk de telefonía IP para sitios externos, actualmente con 750 internos. Dicha plataforma consta de: a) Dos servidores que forman el core de la telefonía actual y hacen las veces de conmutadores para toda las llamadas de telefonía IP. Estos servidores interactúan con el resto de la plataforma telefónica (NEC, gateways, etc.). b) Servidores distribuidos en sitios externos (como Municipios y Centros Comunales Zonales) que hacen las veces de central telefónica local del sitio. c) Dos servidores que realizan la función de central telefónica virtual para sitios con pocos internos (como Policlínicas, Cementerios, Bibliotecas, etc). 3) Un CALLCENTER IPCONTACT con 50 agentes utilizando en su mayoría softphone Zoiper y un IVR de preatención para las llamadas que se reciben al 1950. 4) Tres Gateways CISCO (routers 2921) para interconexión con la NEC y la PSTN (ANTEL) a través de enlaces digitales E1 con señalización ISDN-PRI y R2 digital. - Cada unos de los sistemas posee sus propios internos, en distintas tecnologías, pero que comparten un único plan de numeración de 4 dígitos. Los terminales del Edificio Sede son teléfonos NEC (analógicos y digitales) y los terminales de los sitios externos de telefonía IP son de varias marcas, en su mayoría YEALINK T20. Por mas detalles remitir al ANEXO 1. En el ANEXO 2 se muestran el total de sitios externos con telefonía IP, la cantidad de internos en cada uno de ellos, y la cantidad de llamadas simultáneas que pueden cursar actualmente. 6

El siguiente diagrama muestra la integración de los diferentes sistemas :

El dimensionado actual de enlaces es: - 7 enlaces E1 de conexión con la PSTN para llamadas urbanas y desborde de llamadas salientes a celulares. Los enlaces están configurados como 15 canales entrantes, 10 salientes y 5 bidireccionales. - 1 enlace E1 para llamadas salientes a celulares conectada a la central NEC, configurado como 30 canales salientes. - 5 enlaces E1 entre los equipos gateway de telefonía y la central telefónica NEC.

5. REQUERIMIENTOS TÉCNICOS GENERALES .- El primer despliegue del nuevo SCU deberá sustituir completamente la telefonía IP Asterisk de los sitios externos (señalado como elemento 2 en la lista anterior), sustituyendo progresivamente los demás elementos, hasta ser el único sistema de comunicaciones. En el ANEXO 3 se especifica el dimensionado inicial y el plan de migración en un cronograma a 5 años.

7

- Se admite que la solución propuesta reutilice alguno o todos los componentes de hardware y software actualmente disponibles, ya sea gateways, aparatos telefónicos, etc. En este caso, deberá indicarse claramente cuáles componentes se reutilizarán, de qué forma, y cómo se suple su actual función. - En todo momento se deberá asegurar la integración del nuevo sistema y de los subsistemas legados (NEC, CALLCENTER, gateways CISCO) mientras sigan operativos. Por ej. llamadas entre los diferentes sistemas, plan de numeración único (de 4 dígitos).

6. DIMENSIONADO DEL SISTEMA.1. Configuración inicial Terminales IP: 750 Conexión con PSTN: 8 E1 o comunicaciones equivalentes sobre troncales SIP Conexión con TDM legados: 5 E1 Conexión con otros sistemas ToIP: 80 troncales SIP con CALLCENTER Tráfico total entrante de la telefonía de la I.M.: 100 Erlang en hora pico Tráfico total saliente de telefonía de la I.M.: 50 Erl en hora pico Sitios remotos (con servicio de preatención): 74 sitios externos, con un total de 211 canales a preatendedor. Conferencias: 50 simultáneas, de 6 participantes en cada una de ellas. 2. Configuración máxima Terminales IP: 4000 Conexión con PSTN: 12 E1 o comunicaciones equivalentes sobre troncales SIP Conexión con TDM legados: 5 E1 Conexión con otros sistemas ToIP: 150 troncales SIP con CALLCENTER Tráfico total entrante a telefonía de la I.M.: 200 Erl en hora pico Tráfico total saliente de telefonía de la I.M.: 100 Erl en hora pico Sitios remotos (árboles de preatención): 150 sitios externos, con un total de 500 canales a preatendedor. Conferencias: 100 simultáneas, de 6 participantes en cada una de ellas. El oferente deberá presentar la información del fabricante que permita verificar que se cumplen los requerimientos de dimensionado para la configuración inicial y para la configuración máxima. Se deberá incluir un plan de migración que contemple los equipos, licencias, versiones de software y todos los elementos a agregar para dar servicio adecuado al dimensionado máximo.

8

7. REQUERIMIENTOS TÉCNICOS OBLIGATORIOS.1. La plataforma deberá ser provista bajo la modalidad “llave en mano”, por lo que se deberán proveer todos los elementos necesarios para garantizar el funcionamiento de la misma. 2. La plataforma deberá ser basada en software, capaz de instalarse en servidores de propósito general de la I.M. 3. El oferente deberá acompañar su oferta con un esquema en bloques de la solución ofrecida, describiendo todos los componentes y las relaciones funcionales entre los diferentes módulos.

Procesador de Comunicaciones Este módulo identifica al componente de la solución que deberá controlar las comunicaciones de Voz y Video. 1. La plataforma de comunicaciones deberá considerar una llamada nativa como una comunicación con al menos dos componentes: audio y video. 2. Lo anterior se deberá verificar en la operación normal de modo, por ejemplo, que el plan de numeración sea único e indistinguible para audio y video, sin necesidad de abrir dos planos de numeración diferentes. 3. El plan de numeración deberá ser centralizado en la estructura del procesador de comunicaciones y mantener el actualmente implementado en la I.M. (de 4 dígitos). 4. El procesador de Comunicaciones deberá tener una base de datos de extensiones y usuarios única. Deberá tener un único número de interno por usuario independientemente del dispositivo utilizado y de su cantidad. La solución deberá ser capaz de manejar información de usuario desde el LDAP corporativo (Open LDAP). Se deberá especificar dicha interacción. 5. Deberá estar basado en una arquitectura que permita centralizar el procesamiento de las comunicaciones y su administración en un único ente lógico. 6. El procesador de Comunicaciones deberá implementarse en alta disponibilidad, redundante y ubicados en datacenters distintos, debiendo cada uno de ellos ser capaz de cursar la totalidad del tráfico y servicios de la plataforma. Se deberá describir cómo se logra la arquitectura solicitada. Se deberán incluir los requerimientos de red y detallar la cantidad de servidores necesarios para llegar a la solución. 7. Se deberá describir cómo la solución de comunicaciones escala de 750 a 4000 9

internos administrados por un único punto de administración y describir el patrón de crecimiento. En el ANEXO 3 se especifica el dimensionado de migración en un cronograma a 5 años. 8. La plataforma deberá poder interconectarse a través de una red IP ruteada. El Oferente deberá especificar los requerimientos de ancho de banda y retardo de la interconexión de los nodos para las capacidades solicitadas en este documento. 9. Deberá soportar protocolo SIP para terminales según la RFC3261. 10. Deberá soportar al menos los codec G.711 leyes μ y A, G.729 A y G.722. 11. La operación de los terminales y las facilidades del sistema deberá ser idéntica en todos los sitios. 12. Se requiere que ante una pérdida de uno o ambos servidores de comunicaciones, las comunicaciones activas entre los terminales no se corten. 13. En caso de la caída de un Servidor de Comunicaciones los terminales se registrarán sin necesidad de acciones manuales en el otro Servidor de Comunicaciones. 14. El sistema deberá proveer un registro completo de eventos CDR, donde guarde al menos la información de los siguientes campos: Fecha y hora de comienzo y fin de llamada, identificación de número de origen y destino de la llamada, duración de la llamada, usuario que realizo la llamada, información del estado de la llamada (completada, ocupado, transferido, etc). 15. El SCU deberá responder ante la falta de registros de todos los internos de un sitio. En ese caso no se cursarán llamadas entrantes al número de cabecera o a los internos del sitio. El sistema deberá brindar alguna alternativa al respecto ( mensaje de alerta, llamada a otro interno, etc. ) 16. La plataforma deberá soportar la sincronización vía NTP (network time protocol), la cual debe sincronizar todos los dispositivos que componen la solución.

Gateways Su principal función será la interconexión del nuevo SCU y telefonía, con la red de telefonía pública y los posibles sistemas legados como la central NEC o el sistema de CALL CENTER. 1. Capacidad para establecer al menos hasta 20 llamadas por segundo. 2. Cancelación de eco conforme a ITU G.165 y G.168 para todos los canales de voz simultáneamente, sin depender de los recursos empleados por el sistema, 128ms de buffer. Si se implementa en software, deberá indicarse claramente cómo se 10

realiza, señalando que cancelador emplea y su impacto en el desempeño de los equipos. En particular, no se acepta la cancelación de eco MGII/MKII nativa de Asterisk. 3. Jitter buffer para al menos hasta 200 milisegundos 4. Detección/inserción silencios y audio de confort. 5. Deberá soportar Supresión de silencio. 6. Transcodificación para G.729ab, G.726, G.711 ley A y ley μ para 400 transcodificaciones simultáneas, sin depender de los demás recursos empleados por el sistema. Debe poder ser ampliable hasta al menos un 25 %, sin crecimiento alguno de hardware ni software, excepto mediante crecimiento en placas dedicadas de transcodificación. 7. Soporte para SIP/RTP (y SIP trunking),RTCP, SRTP. 8. Deberá soportar al menos conexión a troncales R2, ISDN PRI y BRI (Digital) con direccionalidad (lineas entrantes, salientes y bidireccionales), de modo configurable y simultaneo. 9. Soporte T.38 (FAX) 10. Todas las interfaces hacia afuera del módulo deberán ser RJ45, incluyendo las interfaces E1. 11. Redundancia De Red Telefónica: El modulo Gateway deberá estar diseñado de modo tal que en caso de caída de uno de los servidores el sistema siga funcionando con todos los enlaces PRI. Desde la perspectiva del usuario: Frente a fallas del sistema de gateway, que produzcan la interrupción de las llamadas telefónicas en curso, los usuarios deberán poder tener nuevamente disponibles los servicios al intentar volver a llamar. 12. Deberá soportar QoS 802.1p/q y Diffserv. 13. Deberá soportar Generación y detección DTMF utilizando RFC2833. Sólo se permite dentro de banda en caso de utilizar G.711. 14. Deberá soportar Simple Network Management Protocol (SNMP) v2. 15. Se deberá permitir la operación simultánea del total de las capacidades solicitadas. Por ejemplo, si se solicitan 30 canales troncales y 30 canales de terminales, se deberá poder utilizar los 60 canales simultáneamente.

11

Servicio de Voz Las funcionalidades para las extensiones deberán incluir como mínimo: 1. Se deberán realizar (iniciar/recibir) llamadas internas en la empresa, es decir, llamadas entre dos usuarios pertenecientes a la red corporativa, independientemente del sistema al que pertenezca (internos NEC, agentes del CALLCENTER) Estas llamadas se establecerán haciendo uso de un plan de numeración especial, que será compartido por todas las líneas de la IM, de la forma 1950 XXXX para llamadas desde el exterior, y 4 dígitos para las llamadas internas. 2. Se deberán recibir llamadas externas entrantes, es decir, llamadas originadas en un usuario cualquiera de la Red de Telefonía Pública Conmutada (PSTN) y/o Red IP no perteneciente a la I.M. hacia un usuario de la red corporativa. 3. Se deberán realizar llamadas salientes al exterior, es decir, llamadas originadas en un usuario de la red corporativa cuyo destino es un usuario de la Red de Telefonía Pública Conmutada (PSTN) o Red IP no perteneciente a la IM. 4. Deberá poder hacerse distinción entre llamadas internas y externas, cuando se pretenda asignar o hacer uso de alguna facilidad. 5. Deberá suministrar el registro de llamadas ( CDR ) internas y externas.

Aspectos del Encadenamiento: 1. La plataforma ofrecida deberá proveer al usuario tono de invitación a marcar, recolectar los números marcados y encaminar de acuerdo a estos. 2. En caso de que el usuario desee hacer una llamada hacia abonados de la Red de Telefonía Publica Conmutada (PSTN) se basará en la marcación de un prefijo saliente (prefijo escape) seguido del número correspondiente al abonado llamado. Deberá tenerse en cuenta que el prefijo de escape deberá ser de un dígito (0-9) configurable. Deberán aceptar más de un prefijo de escape. 3. La plataforma deberá soportar un plan de numeración interna de hasta 10 dígitos. 4. La plataforma deberá soportar rutas alternativas transparentes al usuario, las cuales se utilizarán en caso de congestión o caída de rutas principales, sin que exija al usuario agregado de códigos o dígitos al número original. 5. Deberá proveer ruteo inteligente de llamadas, según el horario y el destino que elija el usuario, eligiendo entre varios proveedores la salida mas conveniente. 6. Para realizar una llamada entre usuarios de la red corporativa se deberá marcar solamente el número de extensión. 12

7. Se deberá soportar la norma T.38 para permitir el envío y recepción de facsímiles.

Servicios a Usuarios: 1. Las llamadas entrantes de Red de Telefonía Pública Conmutada (PSTN) deberán presentar la identificación del llamante (ANI). 2. Se deberá permitir asociarle un nombre al número de extensión. 3. Las llamadas internas entrantes deberán presentar nombre y número de extensión del llamante. 4. Las llamadas internas salientes deberán mostrar nombre y número de extensión del usuario llamado. 5. Desvío incondicional de llamadas. Permite a un usuario redireccionar todas sus llamadas entrantes a otro destino programado. El usuario deberá especificar el número de desvío (interno y/o externo). 6. Desvío de llamadas por ocupado. Permite a un usuario redireccionar sus llamadas a otro destino, cuando se encuentra en condición de ocupado. El usuario deberá especificar el número de desvío (interno y/o externo). 7. Desvío de llamadas por no contesta. Permite a un usuario redireccionar sus llamadas a otro destino, cuando una llamada de entrada no es contestada dentro de una cierta cantidad de ring o campanillas o cierto tiempo (15 segundos por ejemplo). El usuario deberá especificar el número de desvío y el número de ringueos o tiempo que el sistema esperará antes de desviar la llamada (interno y/o externo). 8. Desvío de llamadas (Correo de Voz). El servicio deberá permitir al usuario que éste desvíe sus llamadas entrantes a un buzón de voz cuando éste lo determine (incondicional, por ocupado, por no contesta o por demanda cuando el usuario lo determine). 9. Transferencia de llamadas (Explícita). Permite a un usuario desviar llamadas recibidas y contestadas hacia otro teléfono liberando su estación para realizar y recibir otras llamadas. 10. Deberá permitir transferencias supervisadas/asistidas y no supervisadas/no asistidas. 11. Call Park - Captura de llamadas previamente puestas en espera (Recuperar llamadas o dejarlas en espera). Permite a un usuario perteneciente a un grupo retener una llamada y extraerla desde otra estación dentro del grupo. 12. Captura de llamadas. Permite a un usuario perteneciente a un grupo contestar cualquier llamada dentro de un grupo de captura. La captura de la llamada podrá 13

ser general, en este caso directamente se captura la llamada entrante que está llamando en ese momento, y captura dirigida en este caso toma la llamada entrante a un terminal determinado, no las de todo el grupo de captura. Si un usuario escucha que su interno está sonando, el servicio deberá permitir acceder a esa llamada desde otro interno del grupo, ingresando un código en el aparato que tenga más a mano. 13. El sistema deberá permitir que los terminales realicen registro de llamadas (recibidas, emitidas y perdidas). El Terminal deberá registrar al menos 10 llamadas por tipo de llamada. 14. Deberá permitir al usuario llamar a cualquier número registrado, mediante el uso de un listado. El registro deberá contener identificación, fecha, hora. 15. Transferencia de llamada con conferencia. Permite a un usuario perteneciente a un grupo hacer una transferencia de llamada, después de haber realizado una conferencia. 16. Llamada en espera. Permite a un usuario que esté cursando una llamada, recibir una indicación de una segunda llamada entrante, y deberá permitir dejar la primera llamada en espera con la entrega de música y/o algún mensaje pregrabado, y atender la segunda. Especificar los tipos de indicación posible. 17. Música en espera. En los casos en que la llamada quede estacionada, por ejemplo mientras se hace una transferencia, o porque es una segunda llamada entrante, el SCU suministrará un mensaje de música en espera. El mensaje a sumistrar debe ser customizable, y deber proveerse un mecanismo para cambiar de mensajes. Deberá soportar alguno de los siguientes formatos de archivos: wav, mp3, flac u ogg; se aceptan conversores homologados. Deberá poder configurarse diferentes música en espera o mensajes para las distinta oficinas o sitios externos que utilicen el SCU. 18. Retención con consulta. Permite a un usuario que esté cursando una llamada, dejarla en espera mientras realiza una consulta a otra línea telefónica, sin perder la llamada inicial. 19. Bloqueo/Desbloqueo ID de extensión (número y nombre del usuario). Permite al administrador del sistema bloquear/desbloquear la entrega de identidad de una extensión en forma permanente. 20. No Molestar. Permite a un usuario poder dejar su línea no disponible para todas las llamadas entrantes. El usuario que llama recibe en su teléfono un mensaje que le indica que el usuario al que está llamando no desea ser molestado. Es deseable que se pueda activar para ciertos horarios preprogramados por el usuario. 21. Rellamada del Último Número. Permite a un usuario rellamar de un toque al último número que marcó, independientemente de si la llamada fue contestada o no. 14

22. Múltiples Números por Usuario 23. Usuario con ringing simultáneos. Permite a un usuario tener múltiples terminales (Terminal de escritorio, Terminal de software, móvil, etc.) sonando simultáneamente cuando cualquier llamada es recibida. El primer Terminal desde donde se conteste la llamada interrumpirá el ringueo a los otros terminales. 24. Movilidad. Permite a un usuario tener múltiples terminales (teléfono de escritorio, softphone, móvil, etc.), y seleccionar en cuál de ellos recibir las llamadas. También podría definir un número externo a la plataforma para recibir las llamadas (por ejemplo el número de su domicilio). 25. Línea directa sin marcación. Permite a un usuario establecer una comunicación con sólo levantar el teléfono. 26. Rellamado - Llamada Completada sobre línea ocupada. Permite a un usuario llamante, que encuentra condición de ocupado al efectuar una llamada interna, completar esta automáticamente cuando se libere el usuario llamado, sin necesidad de efectuar una nueva marcación. Este servicio se prestará de la siguiente manera: Luego de la recepción por el llamante A de la señal de B ocupado, y ante la selección del servicio, cuando el usuario llamado B se libera se avisa al usuario llamante A y, a continuación, cuando este descuelgue, se llama al usuario B. 27. Jefa-Secretario (total o incondicional). Este servicio permite que todas las llamadas ofrecidas al teléfono de la jefa se desvíen al teléfono del secretario, sólo las llamadas provenientes del teléfono del secretario con destino al teléfono de la jefa son ofrecidas al teléfono de la jefa. 28. Supervisión-Secretaría. El servicio deberá permitir la visualización del estado de un usuario (ocupado o libre) desde el terminal de la secretaría. 29. Candado digital - Bloqueo de llamadas salientes - (Bloqueo Automático de extensión por horario). El usuario deberá poder dejar su terminal inhabilitado a través de un código para el Bloqueo de todas las llamadas salientes, sólo pudiendo recibir llamadas. La funcionalidad puede tener dos modalidades: a) Bajo demanda: el cliente introduce un comando determinado y bloquea las llamadas salientes, pudiendo realizarlas sólo ante el ingreso correcto de una contraseña. b) Por bandas horarias: En los horarios predeterminados se bloquean las llamadas salientes, pudiendo realizar las sólo ante el ingreso correcto de una contraseña. (Bloqueo Automático de extensión por horario) 30. Códigos de autorización (Claves). Permite a un administrador crear códigos de 15

autorización (CLAVES) para que los usuarios puedan hacer distintas llamadas salientes (DDI, DDN, a móviles). Los códigos de autorización podrán ser creados en forma individual para cada usuario. Los códigos deberán ser al menos de 6 caracteres de longitud. 31. Bloqueo de llamadas entrantes. Este servicio permite bloquear un terminal para recibir llamadas entrantes, sólo pudiendo realizar llamadas salientes. 32. Marcación abreviada individual. Permite comunicarse con otro usuario interno o externo marcando la numeración corta (Ej: 4 dígitos). Deberá permitir a un usuario disponer de una lista individual de marcación abreviada de 10 o más números. Dentro de dicha lista podrán cargarse indistintamente números internos o números de la red pública (precedidos por el código de escape). 33. Marcación abreviada del sistema. Permite comunicarse con otro usuario interno o externo marcando la numeración corta (Ej: 4 dígitos). Deberá permitir armar listas de marcación abreviada, con una capacidad de al menos 300 registros. Dentro de dicha lista podrán cargarse indistintamente números internos o números de la red pública (precedidos por el código de escape). 34. Completar llamada por no contesta (CCNR). Permite a un usuario llamante interno, que encuentra condición de no contesta al efectuar una llamada, completar esta automáticamente cuando se detecta actividad en la línea del usuario llamado, sin necesidad de efectuar una nueva marcación. Este servicio se prestará de la siguiente manera: Luego del intento infructuoso por el llamante A de establecer una comunicación con B, y ante la selección del servicio, cuando se detecta actividad en la línea del usuario llamado B (el usuario B contesta otra llamada y la finaliza, realiza una llamada saliente y la finaliza, levanta el microteléfono y lo vuelve a colgar, etc.) se avisa al usuario llamante A y, a continuación, cuando este descuelgue, se llama al usuario B. 35. Intromisión es una interrupción por voz o tono interfiriendo en la comunicación que se está cursando. Ciertos usuarios tendrán la capacidad de interrumpir comunicaciones. 36. Clases de Servicio – El sistema permitirá que los internos se puedan agrupar en “clases o perfiles”. Luego, basado en estas “clases”, el administrador puede definir y aplicar reglas para comunicar (o no) distintas clases entre ellas, incluso en un sólo sentido. A modo de ejemplo, se podría requerir una estructura piramidal donde siempre una clase superior pueda llamar a cualquier clase inferior, pero en el sentido inverso no. El sistema debe poder operar con al menos 64 clases de servicio diferentes, permitiendo crear reglas con todas ellas. 37. Plan de Llamada / Restricción de llamadas / Privilegios de usuarios. Permite a un administrador establecer diferentes planes de discado de salida para los usuarios.

16

38. Deberá permitir la creación de al menos 8 niveles / planes distintos para usuarios. El administrador podrá autorizar diferentes tipos de llamada por usuario: a) Internas b) Metropolitanas c) Larga Distancia Nacional d) Larga Distancia Internacional e) Móvil f) Niveles Especiales g) Servicios Complementarios (0800; 0900) h) Deberá ser posible restringir llamadas de salidas con el uso de comodines, por ejemplo: 32*, todas las llamadas de salida que comiencen con 32. 39. Plan de Llamada entrante. Deberá permitir el manejo de tablas de conversión de dígitos recibidos de la Red Pública de Telefonía Conmutada (PSTN) o de una PABX. Dichas tablas deberán aceptar insertar y borrar dígitos en cualquier posición. Deberá poder administrar la recepción de entre 1 y 10 dígitos. Deberá disponer de tablas para cada uno de los enlaces de la plataforma. 40. Plan de Llamadas – Desvío/Transferencia. Permite a un administrador que los usuarios no puedan realizar desvío/transferencia de llamadas a destinos no permitidos en el Plan de Llamada – Salida. 41. Configuración de Códigos. Permite a un administrador establecer diferentes códigos para activar los servicios a través del aparato telefónico (DTMF). 42. Inventario de dispositivos. Permite a un administrador a través de la interfaz de administración poder disponer de un inventario de sus dispositivos, teléfonos IP, clientes UC, etc.

Servicios de Video El Servicio de Procesamiento de Video deberá basarse en una aplicación en Servidor que permita implementar un Sistema de Videoconferencia IP, ofreciendo la flexibilidad para montar una solución mixta que combine equipos de videoconferencia de sala y otras posibles aplicaciones como movilidad. Este sistema de video deberá estar integrado al SCU, de esta forma el procesador de llamadas permitirá registrar y manejar los Teléfonos IP en salas de video conferencia y que los propios equipos destinados para Video Conferencia utilicen al procesador de llamadas para generar llamadas de video de manera simple, usando tan solo un número del tipo interno, todos se llamaran entre todos. 17

Además este procesador de llamadas tendrá la posibilidad de registrar no solo a los equipos de video sino también a los teléfonos IP, incluyendo softphone, de manera tal que todos se puedan llamar entre sí. 1. El sistema de Video Conferencia IP debe de poder soportar redundancia a nivel servidores de forma tal que ante una eventual caída de un servidor el/los servidores restantes puedan tomar el control de la situación sin perder el servicio de Video de los dispositivos. El oferente deberá indicar cómo funciona y cómo se implementaría el mencionado procedimiento. 2. El oferente deberá describir detalladamente el grado de escalabilidad que provee el equipo ofrecido, tanto de software como de hardware. 3. El software y el hardware deberán ser totalmente compatibles para garantizar la adecuada ejecución de las aplicaciones la cual deberá ser compatible con el sistema operativo existente. 4. Deberá contar con la capacidad para hacer copias de seguridad de los datos más importantes (Base de datos) y la flexibilidad de guardarlos en otro servidor situado en cualquier lugar de la red IP. 5. La plataforma debe brindar en forma nativa comunicaciones punto a punto. 6. Se deben poder establecer videollamadas punto a punto entre dos usuarios de terminales IP adecuados al fin. Especificaciones mínimas del Servicio de Procesamiento de Video: 1. Consola centralizada de administración, monitoreo y aprovisionamiento de configuración de los dispositivos de videoconferencia, para facilitar su manejo, control y actualizaciones de firmware. 2. Directorio centralizado que permita actualización directa de los números y nombres de las salas de videoconferencia y acceso al mismo desde el equipo de video para facilitar su uso y evitar directorios locales dispersos. 3. Control de Admisión de llamadas y control del acceso a los servicios de videoconferencia mediante restricción de anchos de banda para llamadas de voz y video por sitio, como así también restricciones por plan de marcado. 4. Plan de Marcación Unificado. No se aceptarán llamadas por direccionamiento IP. 5. Soporte de protocolos estándares SIP, BFCP, H.323, H.239, LDAP/H.350

18

6. El Servidor del sistema debe contar al menos con un puerto 10/100/1000BaseT. 7. La administración del sistema debe poderse realizar usando exploradores como Mozilla FireFox 38 o Chromium 41. 8. El sistema propuesto deberá contar con la posibilidad de crecer hasta 100 terminales de videoconferencia, sin necesidad de hardware adicional. 9. Deberá tener mecanismos de recuperación en caso de desastre. 10. Deberá tener niveles de permisos basados en roles. 11. Deberá permitir la creación de áreas y asignación de los dispositivos a dichas áreas para segmentar la administración. 12. Deberá controlar los dispositivos y recursos en base a políticas. 13. Soporte de SNMP. 14. Contar con mecanismos de seguridad

para el cifrado integral de las

comunicaciones (AES para cifrado de medios, soporte de TLS para señalización). 15. Deberá soportar HTTPS 16. Deberá permitir actualizaciones de software, ya sea manuales o programados, de los dispositivos administrados. 17. Deberá soportar el aprovisionamiento (configuración centralizada) de los dispositivos, ya sea manual o programada. 18. El sistema deberá ser capaz de generar archivos para diagnóstico, al menos de trazas (traces). 19. Debe crear un reporte CDR con datos como fecha, hora, duración de llamada, velocidad, número / usuario al que se marcó. El reporte CDR debe tener capacidad de ser exportable. 20. Herramienta para establecer parámetros de seguimiento de trazas (trace) . 21. Herramienta para recolectar trazas. 22. Si existiera redundancia en caso de falla de uno de los sistemas de procesamiento 19

que el otro continúe automáticamente. Durante la conmutación del procesador las comunicaciones establecidas no serán liberadas ni deberán sufrir alteraciones. Gestión, Administración, Supervisión y Mantenimiento: 1. El elemento principal de gestión deberá ser la propia consola de administración del Servicio de Procesamiento de Llamadas. A él se deberá acceder principalmente mediante un cliente web, para su administración, configuración, etc.

Servicio de Conferencias de Video (MCU) El Servicio de Conferencias de Video (MCU) deberá cumplir con los siguientes requisitos mínimos: 1. Unidad de multipunto centralizada independiente de los equipos terminales. 2. Capacidad de soportar, en presencia continua o alterna (todos los participantes de la conferencia son mostrados en todo momento), un mínimo de 5 comunicaciones en formato Full HD 1080p a 30 cuadros por segundo, o 10 comunicaciones en formato HD 720p a 30 cuadros por segundo o 20 participantes en resolución estándar (SD). 3. Ser capaz de soportar resoluciones 1080p/30fps en forma nativa. 4. Soportar llamadas de mínimo 3Mbps por llamada establecida. 5. Capacidad de soportar comunicaciones de audio y video en protocolo SIP. 6. Soportar H.263 y H.264. 7. Soportar el estándar de envío de contenido basado en BFCP. 8. Soportar codecs de audio G.711, G.722 y G.729 como mínimo. 9. Soportar los distintos layouts o formas de mostrar a los participantes de la conferencia en el modo presencia continua o alterna. 10. Soportar transcodificación de los codecs antes mencionados. 11. Soportar la creación de salas virtuales de conferencia vía un sistema de agenda web, con capacidad incluir participantes y salas. 12. Soportar conferencias “ad-hoc”. 13. Soportar AES, TLS. 14. PIN de seguridad para las conferencias.

20

15. Herramienta de gestión basada en Web. 16. Asignar características como ancho de banda máximo, tipo de visualización, codec de video, layout para cada una de las conferencias “ad-hoc”. 17. Soportar conferencias gestionadas por operador con herramientas que faciliten esta funcionalidad. 18. Cada puerto debe ser transcodificado individualmente y la resolución que recibe cada participante deberá mantenerse por más que otros usuarios en la misma conferencia ingresen con una resolución inferior. 19. El sistema de Videoconferencia contará con un sistema de agenda que permita las siguientes funciones: -

Deberá poseer una interfaz que permita calendario de conferencias, tanto punto a punto como multipunto a través del o los MCUs registrados en el sistema.

-

También deberá contar con la posibilidad de agenda conferencias punto a punto sin involucrar ningún MCU.

-

La programación deberá poderse realizar vía web.

-

Dentro de la programación de las conferencia deberá ser posible, al menos: o Especificar el MCU donde se realizará la conferencia. o Especificar si el usuario que programa será el dueño de la conferencia. o Especificar contraseña para la conferencia.

-

Debe tenerse la posibilidad de programar conferencias recurrentes

-

Una vez iniciada una conferencia agendada, se deberá tener la capacidad de monitorear en tiempo real las conferencias y: o Permitir extender la duración de la conferencia. o Permitir poner claves a las conferencias. o Ver el estado de la conexión de los usuarios a una conferencia. o Permitir iniciar y terminar conferencias. o Permitir agregar usuarios a la conferencia. o Permitir cambiar el layout de video. o Permitir silenciar participantes de audio y video.

21

Sala de conferencias (Meeting room) de voz 1. La solución deberá manejar conferencias de voz, que podrán ser originadas por un usuario o salas para conferencia con acceso controlado y seguro. 2. Conferencia. Permite a un usuario establecer comunicaciones simultáneas con otros usuarios. La solución deberá permitir al menos 50 conferencias simultáneas de al menos 6 participantes cada una pudiendo utilizar codec G.711 y G.729 simultáneamente (con terminales adecuados al fin). Los participantes podrán ser tanto otras extensiones dentro de la organización, como números externos. 3. Cada conferencia deberá poder ser originada por un solo usuario a demanda, sin estar programada previamente. 4. El sistema deberá soportar la capacidad de dar a los usuarios un número de reservación para conferencia con acceso controlado y seguro (numero de conferencia y código de seguridad), el cual podrá ser programado previamente. La sesión podrá abrirse desde un teléfono interno, un teléfono externo a la solución (móvil o fijo) con tan solo marcar el número asignado a la conferencia.

Mensajería Instantánea (chat) 1. El SCU deberá brindar la funcionalidad de mensajería instantánea para todos los usuarios o sea la transmisión de texto y envío de archivos sobre la red de datos local en tiempo real. 2. Se deberán almacenar todos los mensajes cursados por un lapso mínimo de un mes. En caso de no cumplir dicho requerimiento, el sistema deberá proveer un mecanismo automático de exportación de los mensajes cursados al menos en los siguientes formatos: csv, txt o xml. 3. Deberá soportar el protocolo XMPP. 4. Deberá mostrar una lista de contactos y el estado de los usuarios (disponible, ocupado, ausente, etc).

Presencia 1. La plataforma deberá contar con una herramienta que le permita publicar al usuario su estado de presencia, fijándolo de forma manual desde un cliente UC o tomando 22

automáticamente el mismo de la actividad registrada en el teléfono. Esta facilidad otorga la capacidad de localizar a un destinatario de comunicación, ver su disponibilidad y la forma de acceso adecuada (voz, video, chat) mediante un cliente que indique el estado de otros usuarios (ocupado, disponible, en escritorio, en móvil, en video llamada, no molestar, etc.) 2. El SCU deberá utilizar al Softphone y/o Teléfono IP para presentarle al usuario los estados de presencia, y de esa manera fijar y publicar su situación (Disponible, ocupado, ausente, en reunión, etc).

Servicios de Pre-atención, Correo de Voz El sistema de pre-atención y el correo de voz debe ser centralizado y residir en los datacenters de la IM, desde donde brindará servicio para toda la plataforma. Pre-atención: 1. El sistema de pre-atención deberá permitir el armado de menús y submenús anidados (esquema funcional de árboles) para presentar a las personas que llaman un conjunto de opciones que deberán ser seleccionadas por medio de las teclas del teléfono. 2. Deberá permitir al menos una pre-atención por cada oficina o sitio externo que utilice la solución. 3. En la configuración inicial se deberá soportar el dimensionado, en cantidad de locales externos y número de canales simultáneos, indicados en el ANEXO 2. 4. La solución deberá poder escalar hasta cuatro veces mas de los valores iniciales respecto a la cantidad de sitios externos o árboles de preatención, y de comunicaciones simultáneas. Se deberá indicar el equipamiento que fuera necesario para soportar ese crecimiento. 5. Deberá permitir derivar las llamadas a la persona correspondiente como: una operadora, un número de interno o un grupo. La configuración y operación de este servicio deberá ser modificable por horarios, por ejemplo, horario de trabajo y horario fuera de las horas de atención. Deberá ser posible que el administrador pueda grabar diferentes saludos de bienvenida. 6. La solución de atención automática de llamados entrantes permitirá reproducir mensajes de bienvenida, ofrecer opciones con árboles de al menos 3 niveles o instancias, y derivar las llamadas a cualquier interno de la plataforma de comunicaciones de la IM. 7. Deberá suministrar la funcionalidad de música en espera, que podrá ser distinta 23

para cada preatendedor. Deberá soportar alguno de los siguientes formatos de archivos: wav, mp3, flac u ogg; se aceptan conversores homologados. Correo de Voz: 1. La solución debe permitir a los usuarios tener una casilla que permita grabar y escuchar los mensajes de los llamadores cuando estos encuentran la línea ocupada o no contesta. 2. La solución deberá contemplar un servicio de voz que sea accedido por los usuarios a través de un número y un código de acceso, que les permita revisar sus correos de voz y además configurar sus preferencias. 3. La capacidad de almacenamiento del correo de voz debe ser tal que admita 3 minutos por cada buzón de voz (considerando la existencia de uno por usuario). Así mismo, es requerimiento que los últimos 10 mensajes depositados en el buzón de voz se mantengan por al menos 30 días.

Tarificación 1. La plataforma deberá contar con una herramienta de gestión del gasto telefónico. La misma deberá contar con una base de datos centralizada que lleve los registros de llamadas CDR, con la información mínima de fecha y hora de comienzo y fin de la llamada, origen y destino de la misma. 2. El sistema de tarificación deberá tener acceso a los datos del CDR mediante una interfaz de red IP. No se aceptan soluciones solo con interfaces seriales. 3. El sistema de tarificación deberá brindar un acceso vía web para los usuarios. 4. El sistema permitirá obtener información por centro de costo y de manera consolidada. 5. El sistema deberá permitir, por medio de un sencillo procedimiento de renovación de tablas de precios, disponer siempre de las tarifas actualizadas. Incluir detalladamente el procedimiento. 6. El sistema deberá mantener almacenada la información del tráfico telefónico en el servidor por al menos 3 meses. 7. Deberá proveerse un mecanismo automático de exportación del registro al menos en los siguientes formatos: csv, txt, xls o xml. Deberá contener al menos la información de los siguientes campos: Fecha y hora de comienzo y fin de llamada, identificación de numero de origen y destino de la llamada, duración de la llamada, usuario que realizó la llamada. 24

Movilidad El SCU deberá brindar movilidad a los usuarios, de modo que los mismos puedan usar el SCU tanto desde un aparato de interno, un softphone, un smartphone o dispositivo móvil con conexión a una red inalámbrica corporativa, o con un terminal móvil con conexión a través de Internet o por redes celulares. 1. El SCU deberá brindar la posibilidad de autenticar a los usuarios y obtener el perfil del mismo (extensión, marcaciones abreviadas, correo de voz, etc.) en cualquier teléfono, mediante contraseña o clave de identificación. 2. Se requiere que el SCU soporte comunicaciones de voz mediante una infraestructura inalámbrica de tipo 802.11, de manera que las extensiones puedan acceder a las funcionalidades de telefonía disponibles mediante terminales de una red Wi-Fi. 3. Todas las posiciones de la plataforma deberán disponer de la facilidad que permita configurar en el SCU un número único de usuario, de manera que éste pueda recibir la llamada tanto en la extensión de software, hardware, o un número que el usuario configure (móvil, fijo externo, etc.). 4. El SCU deberá brindar las facilidades de movilidad para cualquiera de los siguientes tipos de terminales y conexiones: - dispositivo IP conectado a la LAN corporativa (interno IP, softphone en PC) - dispositivo IP conectado a la WLAN (smartphone o dispositivo móvil con software softphone o aplicación). - smartphone o dispositivo móvil externo conectado a Internet. - terminal de telefonía celular. 5. Se deberá proveer la aplicación de software para los smartphone móviles, para al menos los sistemas operativos Android e IOS. 6. Si el usuario recibió las llamadas en su teléfono móvil, habiendo pasado ésta por la plataforma, podrá regresar a su escritorio y tomar nuevamente la llamada en su teléfono IP sin que se pierda la llamada, es decir, el control de la llamada siempre la debe mantener el SCU. Todas las transferencias de llamadas se generarán, sin que el usuario llamante perciba el cambio de Terminal. 7. Cuando una llamada de la oficina no pueda ser contestada desde el teléfono móvil (siempre que la llamada sea ingresada a través del SCU), la llamada deberá ser enviada al correo de voz de la empresa y no al correo de voz del móvil.

25

8. Los usuarios deberán poder enrutar la llamadas de su oficina a cualquier dispositivo. Esta opción deberá configurarse por perfiles, y ser habilitada por el administrador. 9. El SCU permita que dispositivos móviles en Android e iOS accedan desde Internet sin necesidad de que los dispositivos móviles tengan una VPN activa y al mismo tiempo se encripte el audio, señalización y video de los mismos. El oferente tiene que indicar como logra esta funcionalidad, tipo de licencia y software para tal fin.

Conferencia web y Colaboración El SCU deberá proveer herramientas de colaboración, que permitan la comunicación entre dos o mas usuarios compartiendo datos. Deberá soportar al menos 5 salas simultáneas con 20 participantes en cada una. Las funcionalidades a ofrecer a los usuarios que participan en las conferencias son: 1. Video streaming - ofrecer a la audiencia imágenes de cámaras o archivos multimedia. 2. VoIP – audio en tiempo real entre los participantes, mediante el uso de parlantes y/o vinchas, o con el uso de terminales para salas de conferencia. 3. Chat – chat de texto para hacer/responder preguntas. Puede ser chat público u oculto (participante a presentador) 4. Compartir pantallas/escritorio/aplicaciones – los participantes pueden ver el escritorio del presentador, ejecutar aplicaciones, o tomar control en forma remota del escritorio. 5. Presentaciones tipo diapositivas – se presentan imágenes a la audiencia, con herramientas de marcado de texto, punteros, etc., como ayuda para clases o presentaciones. 6. Pizarrón – permite hacer notas en un pizarrón virtual o remarcar texto en las presentaciones. 7. Push de links – permite presentar URLs o script que permitan a los participantes ingresar a sitios web o iniciar sesiones en aplicaciones. 8. Registro de eventos – que permite a los usuarios grabar las presentaciones para posterior uso.

Funcionalidades para discapacidad auditiva La plataforma deberá proveer la capacidad de conversiones speech-to-text, y text-tospeech, de forma que una persona con discapacidad auditiva pueda participar en comunicaciones de voz con interlocutores. Se permiten integrar soluciones de terceras 26

partes para cumplir con este requisito.

Fax Server Actualmente la I.M. cuenta con 220 faxes analógicos distribuidos en distintas oficinas y dependencias, enviando un promedio de 150 faxes de 3 paginas al día. 1. El SCU deberá proveer la funcionalidad de fax server, de forma que los usuarios conectados a la red IP corporativa puedan recibir y enviar faxes desde sus PC de escritorio. La función del fax server es aceptar documentos de los usuarios, convertirlos en fax y transmitirlos, así como recibir fax entrantes y almacenarlos, o entregarlos a los usuarios. 2. El sistema de fax server deberá soportar al menos la cantidad actual de equipos y faxes enviados, ser centralizado, y proveer funcionalidades de resilencia y recuperación de desastres. 3. Para el envío de fax desde un puesto de usuario el sistema deberá proveer alguno de los siguientes mecanismos: •

Email - envío de mensaje a través de email, opcionalmente con un archivo adjunto, a una dirección de correo particular. El sistema fax server deberá monitorear los correos llegados a esa dirección, y convertir los mensajes a fax y enviarlos. El Mail Transfer Agent (MTA) de la I.M. es Postfix.

•

Impresora virtual - el usuario selecciona el fax server como un servicio de impresión virtual, que recibe de esta forma el archivo a enviar.

•

Interfaz web – el sistema suministra una interfaz web que permite al usuario subir los archivos a transmitir por el fax server.

4. Para la recepción de fax y entrega a un usuario el sistema deberá proveer alguno de los siguientes mecanismos: •

Email – el usuario recibe un correo con el fax que le es enviado como archivo adjunto en formato PDF, TXT o TIFF.

•

Almacenamiento - Los fax recibidos quedan almacenados como archivos en formato PDF, TXT o TIFF, en un directorio al que el usuario puede acceder cuando es avisado.

•

Interfaz web – permite el login del usuario para chequear y descargar los fax recibidos, que quedan almacenados como archivos en formato PDF, TXT o TIFF.

5. El sistema deberá proveer un mecanismo de certificación de envío de fax.

27

6. El SCU deberá permitir el uso de terminales de fax analógicos legados, mediante la utilización de adaptadores IP tipo ATA, utilizando el protocolo T.38.

Session Border Controller La solución deberá incluir las funcionalidades de Session Border Controller (SBC), que deberá soportar al menos las siguientes características: Seguridad: 1. Ocultar la topología de red - Mediante NAT a nivel de la dirección IP en la capa de red y SIP a nivel de la capa de aplicación. 2. Firewall de aplicaciones de voz - Evitar, entre otros, ataques de denegación de servicio de telefonía (TDoS). Capacidad de control de acceso, inspección y monitoreo. 3. Encriptación - Encriptación de la señalización y el audio y/o video en caso de ser requerido (por ejemplo para comunicaciones sobre Internet, usando al menos TLS y SRTP) Interoperabilidad e Integración: 4. Certificación - En caso de que el SBC sea de una marca diferente al resto del SCU, se deberá presentar la certificación que muestre la compatibilidad entre los equipos, incluyendo que características son compatibles y cuales no entre ambos. 5. Interconexión de protocolos - SIP-SIP (entre distintas implementaciones del protocolo de diferentes fabricantes) 6. Interconexión de audio - Transcoding y/o transrating entre diferentes codecs 7. Video - Soporte para señalización y seguridad asociada a llamadas de video, incluyendo transcoding y transrating entre diferentes codecs. Debe soportar al menos los codecs H.264 y VP8. 8. Escalabilidad - Dado los requerimientos de interconexión anteriores, así como la necesidad de encriptación, el SBC deberá tener hardware dedicado (como DSPs) para soportar dichas tareas.

Control de sesiones: 9. Control de admisión de llamadas (CAC) - Calcular el ancho de banda para asegurar disponibilidad de recursos para realizar nuevas llamadas. 28

10. Alta disponibilidad - Así como el resto de la solución, el SBC deberá estar en alta disponibilidad, y ante fallas en uno de los SBCs el otro deberá poder manejar todo el tráfico en curso. Además si la red o el SBC fallan, el sistema permitirá redirigir el tráfico por otro camino a definir por el administrador del sistema. Resiliencia: 11. Ruteo - El SBC deberá brindar la capacidad de enrutamiento de llamadas entre diferentes redes de operadores (carriers), basado en costo, día, región , calidad (QoS), usuario, dirección IP, IP de red, tipo de codec, nombre de dominio u otras variables. Por ejemplo si el SBC detecta errores en una llamada que se cursa sobre determinada red, puede enrutar las llamadas siguientes sobre redes que no están teniendo problemas de performance. 12. Balanceo de carga de troncales SIP - deberá soportar conectividad sobre mas de un troncal SIP de forma de ofrecer balance de carga en caso de problemas de calidad o disponibilidad. 13. Redundancia geográfica de proveedores de servicio - Para lo que deberá soportar servicios de alta disponibilidad de troncales SIP con failover tipo stateful. 14. Salida local a PSTN - deberá proveer conectividad a servicios locales TDM en caso de caída de los enlaces IP. Administración y monitoreo: 15. Facilidad de configuración - deberá presentar interfaz de comandos de línea CLI, además de una interfaz gráfica de usuario GUI y templates prearmados para fácil configuración del SBC. 16. Alarmas - notificaciones en tiempo real de eventos de red, seguridad, recursos y demás eventos que afecten la calidad de las sesiones. 17. Troubleshooting - herramientas para la detección y solución de fallas, p.ej. con puntos de demarcación entre redes para aislar y solucionar problemas de señalización o de datos (media).

Terminales La IM brindará a sus funcionarios, terminales acordes a su función. Para lo cual se definen 3 modelos de teléfonos, un videoteléfono, y equipos para sala de reuniones. La solución deberá soportar distintos tipos de terminales: •

29

Teléfonos IP de terceros (terminales YEALINK SIP-T20P, POLYCOM, ATCOM, ya descritos en la sección BASE INSTALADA).

•

Softphones de software propietarios y genéricos (Zoiper descrito en la sección BASE INSTALADA).

Además los siguientes terminales, descritos a continuación:

Teléfono IP propietarios de escritorio

Teléfono IP gama baja: 1. Deberá soportar todas las funcionalidades definidas anteriormente como servicios de voz. 2. Deberá incluir un switch dual FastEthernet. 3. Deberá soportar el estándar PoE 802.3af. 4. Deberá contar con pantalla de al menos dos líneas. 5. Deberá disponer de acceso al registro de llamadas (historial) 6. Deberá incluir la funcionalidad de manos libres full-duplex 7. Deberá disponer de indicación gráfica o lumínica de mensaje en buzón de voz. 8. Deberá contar con registro de llamadas perdidas, contestadas, llamadas de salida (mínimo 25 registros). 9. Deberá soportar alimentación mediante fuente externa. 10. Deberá soportar protocolo SIP. 11. Deberá soportar protocolo IPv4, DHCP, TCP/UDP/RTP/RTCP, LLDP. 12. Deberá soportar RSVP, SNMP v2, NTP, en caso de que no lo haga el SCU. 13. Deberá soportar 802.1q, DiffServ. 14. Deberá soportar 802.1x 15. Deberá soportar codec de audio G.711, G.729 A/B. 16. Deberá poseer botón de: Rediscado, Hold, Transfer, Mute y Control de volumen

Teléfono IP gama baja (inalámbrico): 1. Se deberán soportar todas las funcionalidades del “Teléfono IP gama baja”.

30

2. Se debe conectar a su base en forma inalámbrica, no Wi-Fi. 3. Debe soportar DECT (Digital Enhanced Cordless Technology)

Teléfono IP gama intermedia: 1. Se deberán soportar todas las funcionalidades del “Teléfono IP gama baja”. 2. Al menos 2 botones para funciones programadas por el sistema 3. Conexión para vincha 4. Soporte de RSTP (AES-128) 5. Capacidad para ejecutar aplicaciones XML o WML 6. Acceso a directorio corporativo

Teléfono IP gama alta (videoteléfono): 1. Se deberán soportar todas las funcionalidades del “Teléfono IP gama intermedia”. 2. Pantalla color de al menos 5 pulgadas. 3. Cámara de video incluida con resolución mínima de 720p/30fps, tilt manual y led de actividad 4. Deberá incluir un switch dual GigaEthernet. 5. Soporte Bluethoot. 6. Un puerto USB 2,0 o superior (como mínimo)

Equipos para salas: Se requieren equipos de videoconferencia Full HD para: •

Salas Tipo 1 1. El equipo de videoconferencia de cada Sala Tipo 1 estará ubicado dentro de una sala de aproximadamente 4x4 metros para 5 o 6 integrantes. 2. Codec físico en hardware (no basado en PC) que convierta cada pantalla plana (LCD o LED) en un flexible sistema de videoconferencia Full HD vía un conector HDMI.

31

3. Protocolo de señalización SIP. 4. Codec de Voz: G.711, G.722, G.729, G.729ab, G.711a, G.722.1 5. Codec de Video: al menos H.263, H.263+, H.264. 6. Auto control de ganancia y cancelación de eco para el audio. 7. Calidad de Servicio: IEEE 802.1Q (VLAN), Differentiated Services (DiffServ), IEEE 802.1p. 8. Velocidad máxima de transferencia de 3 Mbps. 9. Cámara Full HD 1080p del tipo PTZ con zoom 3X como mínimo. 10. Cámara con foco automático o manual, brillo y balance de blancos. 11. Se valorará que la cámara este incorporada al codec físico de manera de que el equipo de videoconferencia sea compacto. 12. Micrófono incorporado al codec físico y conector del tipo mini-jack para un micrófono externo adicional. 13. Control remoto. 14. Compartir contenido vía BFCP para SIP. 15. Enviar video en full HD hasta 1080p30 y compartir documentos hasta WXGAp/5. 16. Una salida de video HDMI para presentar el video en una pantalla. 17. Una entrada de video analógica con la finalidad de compartir el contenido de una PC mediante su salida de monitor VGA. 18. Una entrada de video digital HDMI. 19. Alimentación del codec vía PoE y opcional eléctrica vía fuente de poder externa. 20. Accesorio para montaje en pared. •

32

Salas Tipo 2

1. El equipo de videoconferencia de Sala Tipo 2 estará ubicado dentro de una sala de aproximadamente 8x4 metros para 8 o 9 integrantes. 2. Codec físico en hardware (no basado en PC) que convierta la pantalla plana (LCD o LED) en un flexible sistema de videoconferencia Full HD vía conector HDMI. 3. Protocolo de señalización SIP (valorado contar con H.323). 4. Codec de Voz: G.711, G.722, G.722.1, G.728, G.729. 5. Codec de Video: al menos H.263, H.263+, H.264. 6. Auto control de ganancia y cancelación de eco para el audio. 7. Calidad de Servicio: IEEE 802.1Q (VLAN), Differentiated Services (DiffServ), IEEE 802.1p. 8. Velocidad máxima de transferencia de 6 Mbps. 9. Cámara Full HD 1080p del tipo PTZ con zoom óptico 10X. 10. Cámara con foco automático o manual, brillo y balance de blancos. 11. Micrófono externo al codec tipo de mesa con cable incorporado (se acepta inalámbrico) con un mínimo de 6 metros de largo. 12. Control Remoto. 13. Compartir contenido vía BFCP para SIP y H.239 para H.323. 14. Enviar video en Full HD hasta 1080p60 y compartir documentos hasta 1080p. 15. Dos salidas de video HDMI para presentar el video en una pantalla y el contenido compartido en otra pantalla si así se requiere. 16. Una entrada de video analógica con la finalidad de compartir el contenido de una PC mediante su salida de monitor VGA. 17. Una entrada de video digital HDMI. 18. Alimentación del codec vía fuente de poder externa. 19. Accesorio para montaje en pared del codec. 20. Accesorio para montaje de cámara. 21. Una entrada de audio analógica auxiliar para segundo micrófono.

Cliente UC para PC:

1. El cliente de UC podrá ser web, compatible con Firefox 38 o Chromium 41. 33

2. Deberá soportar todas las funcionalidades definidas anteriormente como servicios de voz. 3. El cliente de comunicaciones unificadas para el computador, debe tener la capacidad de trabajar en tres modos: • Modo VoIP: En este modo tanto la señalización como la voz viajaran a través de la red de datos hacia el computador del usuario quien podrá comunicarse usando una vincha o diadema (auricular USB). • Modo Conmutador: En este modo la señalización será manejada desde el computador del usuario pero la voz viajará a través de una troncal hacia un número en el que el usuario recibirá y transmitirá la voz. Este modo es importante para casos de trabajo remoto, poco ancho de banda y caso de que el usuario cuente con un teléfono de un PBX diferente. • Modo de Control Compartido: En este modo el usuario tiene todo el control de su teléfono de escritorio o teléfono VPN desde su computador. 4. Deberá contar con indicador de correo de voz. 5. El cliente UC debe contar con un teclado de marcación gráfico que además de mostrar los dígitos deberá mostrar todas las facilidades de telefonía que han sido activados para este usuario. 6. Deberá contar con registro de llamadas perdidas, contestadas, llamadas de salida. 7. Deberá Incluir lista de contactos personales y de la empresa (integración con LDAP). 8. Con esta lista de contactos, el usuario deberá ser capaz de realizar la búsqueda de contactos personales y de la empresa. 9. Con esta lista de contactos, el usuario deberá ser capaz de realizar marcación “click-to-dial” del contacto especificado desde el directorio de contactos. 10. El Softphone deberá soportar el protocolo SIP. 11. Deberá poder cursar comunicaciones con voz y video punto a punto.

Cliente UC para Teléfono Móvil:

1. Se debe proveer el cliente para teléfonos celulares inteligentes, el cual debe admitir al menos los sistemas operativos: Google Android y Apple iOS. 2. Este cliente debe poder brindar servicios de voz y video.

34

Software de Administración del SCU 1. Se deberá suministrar el software necesario para administrar el SCU y los subsistemas componentes. Éste deberá proveer una interfaz web amigable que permita la configuración del sistema así como la detección, reporte de errores, y monitoreo de performance. 2. El Sistema de Administración ofrecerá una vista unificada de toda la infraestructura de Comunicaciones Unificadas y presentará el estado operativo actual de cada elemento de este sistema. Es el encargado de la configuración total del sistema y controla de forma continua el estado operativo actual de los diferentes productos de Comunicaciones Unificadas, incluyendo el procesamiento de llamadas, las aplicaciones, los gateways y los terminales IP y teléfonos. Mostrará alarmas en tiempo real y enviará notificaciones por email (definidas por el usuario), además de proporcionar capacidades de diagnóstico para un rápido aislamiento y resolución de problemas. 3. Deberá proveer al menos funcionalidades básicas de FCPAS (Fault, Configuration, Accounting, Performance, Security / Falla, Configuración, Registro, Desempeño, Seguridad) para poder operar la infraestructura adquirida . 4. Acceso basado en roles - Deberá proveer diferentes niveles de usuarios, con permisos desde solo comandos de lectura hasta usuarios con capacidad completa de administradores de sistemas. Los atributos asociados a cada perfil podrán ser customizados. 5. Se proveerá un Monitor (puede ser un software que corra independiente del administrador del SCU) que supervisa de forma continua las llamadas activas que admiten los productos de Comunicaciones Unificadas, y ofrece notificaciones en tiempo real. 6. El Monitor proveerá métricas de calidad de las comunicaciones, por ejemplo MOS. 7. Herramienta de gestión en entorno gráfico GUI, compatible con Firefox 38 o Chromium 41. 8. Esta herramienta debe ser capaz de parámetros/equipos de la solución vía LAN.

la

administración

de

todos

los

9. Deberá poseer acceso vía CLI, y poseer las mismas funcionalidades de la GUI. 10. Deberá ser administrable vía SSHv2 (claves RSA de 1024 bits) y Web (HTTP y/o HTTPS) opcional. 11. Poder actualizar firmware vía Web y/o vía FTP/TFTP. 12. Debe poderse cargar y descargar configuración en formato de texto. Debe soportar 35

el respaldo de la configuración global, así como la carga de una configuración respaldada o una nueva desde archivo de texto. 13. Soporte RADIUS para acceso administrativo. 14. SNMP v2c o superior. Soporte envío de traps SNMP para poder ser monitoreados por CACTI/NAGIOS. Debe implementar al menos las siguientes MIB: ENTITY-MIB ETHER-LIKE-MIB IF-MIB

Auto Provisionamiento de Terminales 1. El SCU deberá proveer una herramienta con interfaz Web que permita el autoprovisioning de terminales propietarias. En esta herramienta centralizada se definirán las configuraciones, seteos de parámetros y versiones de firmware que tomarán los teléfonos y terminales del SCU que se conecten utilizando DHCP y TFTP. 2. Permitirá manejas solicitudes de usuarios para los servicios de SCU, como líneas, teléfonos, casillas de voz, etc.; para manejar altas, bajas o modificaciones. 3. Proveerá templates de configuración, para configuraciones iniciales o para modificaciones. 4. Además del manejo de configuraciones en forma individual, se proveerá herramientas para la ejecución agendada (con programación de fecha y hora) de procesos en forma batch para configuraciones y cambios. 5. Permitirá distintos niveles de roles para los operadores del sistema, p.ej. para un administrador del sistema, para un usuario común, etc. 6. Además de permitir el aprovisionamiento de teléfonos propietarios, deberá manejar los teléfonos IP legados que se utilicen, de las marcas mencionadas en el ANEXO 1, p.ej. con el suministro de APIs (Application Programming Interface) de integración.

8. REQUERIMIENTOS PARA EL EQUIPAMIENTO.En este ítem se presentan las especificaciones que deberán cumplir los equipamientos informáticos y de servicios para datacenters que se compren para la I.M. Estas 36

especificaciones están orientadas a lograr un mejor aseguramiento de la disponibilidad de los equipos, y serán obligatorias, excepto en aquellos casos en los que, por el tipo de equipamiento específico, la especificación no pueda aplicarse, o no haya en el mercado ningún equipo con la especificación (en tales casos, deberá esta explicito en la compra el motivo). • Requerimientos ambientales • Temperatura de operación: 0 a 40ºC • Temperatura de almacenamiento: -25 a 70ºC • Humedad ambiente de Operación: 10 a 80% • Certificados FCC y UL vigentes • Los equipos a instalarse en racks deberán cumplir lo siguiente: • Rackeables 19'' de frente • Altura en cantidad entera de unidades de rackeo (U), preferentemente de 1U o 2U • Profundidad máxima de 22'' • Los rieles para el rackeo deben ser provistos por el proveedor • Alimentación • Alimentación: 230 VAC, 50 Hz. Cable y toma Schuko (European plug CEE7/4 o CEE 7/7) preferiblemente. • Doble fuente (considerar las fuentes de alta eficiencia, que cumplan un estándar como el 80-PLUS® y ENERGY-STAR®) • Soporte • Al menos 3 años de garantía del fabricante • Servicio de soporte on-site • Para el caso de software de base, soporte certificado de las versiones en uso definidas por cada área. • Protocolos de administración soportados • Syslog • SNMP v2c o superior. Soporte de envío de traps SNMP. • Posibilidad de cargar y descargar configuración en formato de texto.

Requerimientos específicos para servidores (mínimos) • Controladoras de RAID • Discos hot-plug SAS 2.5" 37

• Memoria DDR3 ECC • Mínimo 4 puertos de adaptador de red GB Ethernet • Mínimo 4 slots PCI • Puertos para mouse y teclado USB • Soporte certificado de las versiones de Sistema Operativo definidas por Administración de Sistemas, compatible con la arquitectura de hardware del servidor. • Puerto LAN de administración independiente que soporte IPMI 2.0 y funcionalidad de consola de texto y gráfica remota (funcionalidad similar a kvm IP) Se deberán incluir en la oferta todas las licencias necesarias para realizar el despliegue del servicio entre todos los usuarios, tanto de la parte de servidor como de la parte del cliente. Se valorará el acceso a las licencias en un modelo de licenciamiento específico para el sector de gobierno.

9.

OTROS REQUERIMIENTOS OBLIGATORIOS.-

Garantía del fabricante de Hardware por al menos 3 años, por escrito. • Ningún componente (hardware y software) de la oferta deberá tener “End Of Life” o equivalente anunciada, y si la tuviese deberá ser una fecha mayor a 5 años desde la fecha de apertura de esta licitación. Tampoco se aceptan componentes con “End of Sale” y “End of Support” con una fecha inferior a 3 años. • Soporte y actualizaciones de software por 3 años • Soporte de configuraciones por 3 años

10. CONDICIONES ESPECIALES.Definición de funcionalidades y funciones Algunas funciones solicitadas en el presente documento fueron nombradas con cierta nomenclatura y no todos los fabricantes usan exactamente la misma, cada oferente indicará para cada función como la denomina. El documento también especifica en algunos casos como debe operar determinada función, si el oferente llega a la misma finalidad pero de otra manera a la expresada, deberá indicar como lo logra, y deberá presentar documentación (hoja de datos, carta del fabricante u otros) que lo justifique. Todas las especificaciones mencionadas en este documento son requeridas para el SCU como solución global y algunas de ellas pueden no estar implementadas directamente en el componente especificado. Si una especificación no se cumple en el componente según lo descrito en el presente documento, el oferente deberá indicar entonces en que otro componente de la solución se implementa la misma y presentar documentación (hoja de datos, carta del fabricante u otros) que lo justifique.

38

Marcas Se orienta la búsqueda hacia soluciones reconocidas a nivel mundial. A tales efectos se tomará como referencia el documento de Gartner “Magic Quadrant for Unified Communications” de Agosto 2015, (http://www.gartner.com/technology/reprints.do?id=1-2KYASDI&ct=150810&st=sb) o el último vigente a la fecha. Se descartarán aquellas que no se encuentren en el mencionado documento.

39

40

Interoperabilidad Todos los equipos del SCU deberán ser de una misma marca, de forma de asegurar la compatibilidad entre los dispositivos, disponer de un sistema de administración común, repuestos y soporte técnico. En caso de que la solución de SCU utilice algún subsistema o herramienta de otro proveedor, se deberán presentar las certificaciones del fabricante que aseguren la compatibilidad e integración, y los test específicos que lo avalan.

Instalación La 41

instalación deberá ejecutarse por personal propio de la empresa, no podrá ser

subcontratada, se exigirá la plantilla de trabajo. El o los técnicos que realicen esta tarea deberán tener la certificación necesaria aprobada por la marca proveedora del equipamiento. El oferente, deberá tener en cuenta que la compra es “llave en mano” e incluye servicios de suministro de materiales y elementos ON-SITE, instalación, configuración, soporte, garantía y capacitación en las soluciones, diseños y sistemas requeridos para la puesta en funcionamiento, entre otros. Si para la implementación de la solución el proponente llegare a requerir algún componente de hardware, software, elementos activos, elementos pasivos, servicios, capacitación, obra o configuraciones no contemplados en los requerimientos técnicos, será responsabilidad absoluta del proponente incluirlos y costearlos dentro de su propuesta, o de no estar incluidos en su propuesta, si durante el proceso de ejecución del contrato se establece la necesidad, el proponente deberá asumirlos sin que esto ocasione costos adicionales para la I.M. a los inicialmente establecidos.

11.CAPACITACIÓN. 1. Se deberá cotizar en la propuesta un programa de capacitación y entrenamiento para el personal de la I.M. destinado a la Operación y Administración de los dispositivos. La capacitación deberá dar a cada alumno un nivel satisfactorio de conocimientos sobre las funciones y características de los distintos dispositivos, así como conocimientos prácticos y destreza sobre las funciones, manejo y operación de todos los sistemas que se suministren, incluyendo recuperación ante falla y replicación. 2. Se indicará en la oferta la duración estimada y el programa de cada curso, para el cual la I.M. designará un grupo no mayor a 15 participantes de nivel técnico en cada uno. Deberá cotizar al menos un curso de operación, administración y monitoreo que cubra la totalidad de los componentes del SCU presentado, de al menos 30 horas de duración. 3. La frecuencia y duración de las clases se acordará entre la I.M. y el adjudicatario, pudiéndose eventualmente dividir en subgrupos, para poder capacitar personal de diferentes turnos. 4. El personal de la I.M. deberá ser adiestrado a los efectos de estar en condiciones de identificar y utilizar la documentación elemental del sistema, los manuales y esquemas con el propósito de administrar, operar y monitorear adecuadamente los equipos, así como superar fallas cuando estén a su alcance.

42

5. Estos cursos deberán ser dictados por instructores certificados por el fabricante de los sistemas en los productos objeto del curso, cuyo currículum será incluido en la oferta. La I.M. se reserva el derecho de solicitar el cambio de docente, cuando entienda que el currículum o experiencia del mismo no alcanza el nivel necesario para la capacitación que se ofrece. Esta solicitud deberá ser atendida por el adjudicatario, quien presentará otro docente con las características solicitadas por I.M. 6. La capacitación deberá realizarse en el período comprendido entre la notificación de adjudicación y la recepción definitiva. 7. También se cotizará un curso para el personal de las áreas de ANALISIS FUNCIONAL y MESA DE AYUDA de la I.M. (10 participantes), el cual los entrenará para poder capacitar a los usuarios finales en el manejo del nuevo sistema. Esto incluye la operación de las nuevas funcionalidades y/o terminales.

12.REQUERIMIENTOS PARA LA PROVEEDORA Y EL FABRICANTE.

EMPRESA

1. ANTECEDENTES: El oferente deberá incluir documentación que acredite diseños y soluciones, similares técnicamente y con no más de cinco años de antigüedad. Deberá presentar información de al menos tres (3) instalaciones de mas de 2000 terminales realizadas por el fabricante (en LatinoAmerica) y de al menos tres(3) instalaciones de 200 terminales para la empresa proveedora (en Uruguay). Dichas instalaciones deberán contar con múltiples enlaces troncales E1 PRI y/o R2 hacia distintas centrales, y troncales SIP. Para cada contrato que se presente en esta sección se deberá especificar la siguiente información: El nombre del proyecto y su ubicación. El nombre, dirección y ubicación del contratante, incluyendo persona de contacto. Breve descripción del proyecto y de los servicios específicos prestados (indicando específicamente los ítems similares técnicamente que incluye). Las fechas de inicio y terminación del contrato de proveeduría 2. El oferente deberá proporcionar una descripción del personal permanente que se prevea asignar a los servicios de diseño e implementación, señalando el nombre, títulos académicos y experiencia profesional de cada uno. Deberá adjuntarse la documentación probatoria de los méritos declarados. 3. Dicho personal debe estar certificado por el fabricante de los equipos que forman parte de la oferta, para todos los sistemas de la solución y para todo el equipamiento involucrado. Dicha certificación deberá tener al menos seis meses de 43

antigüedad a la fecha de apertura de esta licitación. Al menos 1 de las personas con certificación deberá poseer título de Ingeniero Electricista, Ingeniero en Computación o similar homologado por la Universidad de la República (UdelaR). 4. La empresa proveedora deberá demostrar tener la capacidad de brindar: •

Servicios de Operación y Mantenimiento (O&M) para el nivel terciario. Los niveles primarios y secundarios de soporte serán realizados por personal técnico de I.M. Deberá proveer un sistema de atención de reclamos y respuesta las 24 horas los 365 días del año.

•

Mantenimiento correctivo de nivel terciario, que deberá incluir reprogramaciones y reconfiguraciones del sistema. El proveedor deberá certificar estar autorizado por el fabricante del sistema para brindar soporte a la plataforma de SCU y deberá tener acceso al Centro de Asistencia del Fabricante las 24 horas los 365 días del año.

•

Disponibilidad de acceso a repuestos, partes y piezas originales, a ser suministrados por cuenta y orden de la I.M.

•

Suministro de actualizaciones de software que desarrolle el fabricante para la plataforma de SCU.

5. ANTIGÜEDAD: El oferente deberá acreditar en su oferta, mediante presentación de documentación de D.G.I. (tarjeta de R.U.T.), una antigüedad en plaza en el giro, no menor de tres (3) años. Cuando se trate de oferentes inscriptos en el Registro de Proveedores de la I.M., dicha antigüedad se podrá verificar en el mencionado Registro.

13.MAQUETA DE COMPATIBILIDAD, INTEGRACIÓN Y FUNCIONALIDADES BÁSICAS. 1. Al oferente cuya propuesta cumpla con los requerimientos técnicos y sea la propuesta económica mas conveniente, una vez adjudicada, se le requerirá a los efectos de comprobar mediante la instalación y configuración de una maqueta, el cumplimiento de funcionalidades requeridas. 2. La aprobación de correcto funcionamiento de la maqueta por parte de la I.M. será condición para la aprobación de la recepción provisoria y primer pago. 3. La empresa oferente dispondrá de 75 días a partir de la notificación de la I.M. para instalar y configurar los equipos en los datacenters de la I.M. 4. La maqueta deberá contar con la infraestructura para: • 44

Probar la integración con los sistemas legados y con la PSTN con al menos

un enlace E1 y con al menos un troncal SIP con cada sistema a conectar. •

Definir 2 sitios externos, con al menos 5 internos cada uno. Cada sitio externo tendrá una estructura de preatendedor con mensajes en 2 niveles, y una cola de operadora.

5. Se verificarán las funcionalidades de: ◦ Integración con sistemas legados y conexión a la PSTN. Posibilidad de realizar comunicaciones entre usuarios de los distintos sistemas, dentro del plan de numeración de la I.M. ◦ Funcionalidades básicas de servicios de voz, video, conferencias, mensajería y presencia, preatención y movilidad. ◦ Funcionamiento de IVR y respuesta a caída de enlaces WAN ◦ Supervivencia y alta disponibilidad ◦ Registros de llamadas ◦ Claves de usuarios y autenticación, integración con LDAP

14. CANTIDADES A COMPRAR. En el ANEXO 3, se suministra el dimensionado de los componentes del SCU objeto de la licitación. Se distinguen 3 categorías de componentes: •

Compra Básica – Son los componentes necesarios para el despliegue inicial del sistema. Corresponde a las celdas pintadas en verde en el ANEXO 3.

•

Compra Opcional – Corresponden a opcionales adicionales a la compra básica, p.ej. hardware para servidores, o funcionalidades adicionales. Corresponde a las celdas pintadas en amarillo en el ANEXO 3.

•

Migración y Crecimiento – Son los componentes que se irán agregando en un plan de 5 años para migrar los sistemas telefónicos legados de la I.M. a la nueva plataforma de SCU. Corresponde a las celdas pintadas en celeste en el ANEXO 3.

El objeto de la presente licitación es la adquisición de los componentes correspondientes a la Compra Básica y a la Compra Opcional La I.M. se compromete a la adquisición de los componentes de la Compra Básica por hasta un máximo de las cantidades indicadas en el ANEXO 3. En caso de que lo considere necesario, la I.M. podrá adquirir adicionalmente alguno o todos los ítems de los componentes de la Compra Opcional por hasta un máximo de las cantidades indicadas en el ANEXO 3. 45

15.EVALUACIÓN Y COMPARACIÓN DE OFERTAS. Se adjudicará la licitación al oferente que: •

Su propuesta técnica cumpla con las especificaciones del presente pliego.

•

La empresa cumpla con lo especificado en los Requerimientos para la empresa proveedora.

•

Se haya aprobado por parte de la Unidad de TELECOMUNICACIONES de la I.M. el correcto funcionamiento de la maqueta realizada para las pruebas de compatibilidad, integración y funcionalidades básicas.

•

Sea la oferta de menor precio, de acuerdo a la evaluación económica del ANEXO 4, que resulta de la inversión inicial y del plan de migración y crecimiento anual a 5 años especificado en el ANEXO 3.

La evaluación económica se realizará teniendo en cuenta la inversión inicial, señalada en la sección anterior (CANTIDADES A COMPRAR) como la Compra Básica y a la Compra Opcional, así como también las inversiones correspondientes a Migración y Crecimiento, de acuerdo al plan de migración y crecimiento anual a 5 años, así como los costos de licencias y del contrato de soporte durante ese período. En la planilla de cálculo del ANEXO 4 se consideran: •

El Valor Neto Presente (VNA) de las inversiones anuales, tanto en moneda nacional como en dólares americanos U$S, considerando las tasas de interés correspondientes.

•

El dimensionado de componentes del ANEXO 3, tanto de la compra inicial (AÑO 0) como del plan de migración a 5 años.

•

La posibilidad de cotización en $ o en U$S, con la tasa de cambio a los efectos de convertir todas las cotizaciones a moneda nacional.

La comparación se realizará respecto al precio del 100% de los ítems solicitados sin tener en cuenta el descuento pronto pago. En caso de empate en el precio, se definirá teniendo en cuenta el mejor plazo y alcance de la garantía. Si se mantiene el empate se definirá teniendo en cuenta el menor plazo de entrega, y si aún en esta etapa persistiera el empate, se definirá teniendo en cuenta la mayor cantidad de antecedentes.

46