memoriaTecnica 306263 - Intendencia de Montevideo.

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