Primera parte

Transcripción

Primera parte

Licitación Pública No. 022 de 2007 de
la Universidad Industrial de Santander
Bucaramanga, Abril 14 de 2008
Señores
Universidad Industrial de Santander
Ciudad
Asunto:
Licitación Pública No. 022 de 2007 – Observaciones a la
Evaluación Económica Final y Evaluación Técnica Final
Por medio de la presente damos a conocer nuestras respuestas sobre todas
las observaciones solicitadas en la evaluación técnica final de la licitación del
asunto. Con este comunicado Colombia Telecomunicaciones S.A. E.S.P.
aclara que cumplimos todos los requerimientos de la licitación del asunto.
Respecto a la observación 4 y 15 acerca de que la solución de Ericsson MXONE, ofertada por Colombia Telecomunicaciones S.A. E.S.P., no cumple los
requerimientos técnicos debido a que no es una solución IP nativa, debemos
decir que SI lo es, basados en la información del Brochure que adjuntamos,
el cual también hacía parte de los documentos entregados en el proceso de
licitación.
En la primera página del catálogo aparece:
“MX-ONE™ is a complete IP PBX that now scales up to 50,000 users. It is
based on open software and hardware, running on the Linux operating
system
and
standard
servers.”
En la segunda página:
“MX-ONE™ caters to all customer scenarios—all-IP, branch offices and
geographically
dispersed
organizations.”
Además:
Media Gateways The function of a media gateway is to form a bridge
between the IP and classic telecommunications worlds. Media Gateway The
Media Gateway is a 19-inch, rack-mounted unit enclosed in a 1U box, with
the following features:
En la definición del media Gateway queda claro que el MX-ONE requiere una
interfaz para ofrecer funcionalidades no IP, por tanto queda claro que la
solución es IP Nativa.
En este momento Ericsson está expidiendo un certificado que avala nuestra
posición.
Gracias y quedamos atentos.
1
Colombia Telecomunicaciones S.A. ESP NIT 830.122.566-1
Transv. 60 No.114 A - 55 Bogotá, Colombia
Tel. 5935399 Fax.5782728 www.telefonica.com.co
Licitación Pública No. 022 de 2007 de
la Universidad Industrial de Santander
Cualquier duda por favor comunicarse con el Gerente Comercial para la UIS
Gabriel
Vargas
al
3164726578
–
3174344949
o
al
[email protected].
Atentamente,
Gabriel Vargas Iregui
Vicepresidencia de Empresas
Colombia Telecomunicaciones S.A. E.S.P. – TELEFONICA COLOMBIA
2
Colombia Telecomunicaciones S.A. ESP NIT 830.122.566-1
Transv. 60 No.114 A - 55 Bogotá, Colombia
Tel. 5935399 Fax.5782728 www.telefonica.com.co
ERicsson MX‑ONE™
Telephony System Version 3.1
MX‑ONE™ is a complete IP PBX that now scales up to
50,000 users. It is based on open software and hardware,
running on the Linux operating system and standard
servers.
MX‑ONE™ supports a rich variety of new and classic
interfaces, such as IP, ISDN and conventional analog
and digital interfaces. MX‑ONE™ consequently smoothly
interacts with both all-IP installations and conventional
telecommunications.
With full MX‑ONE™ deployment, powerful end-user
applications and a management solution complement
the Telephony Server to create a comprehensive, multiconvergence solution.
MX‑ONE™ is based on a truly distributed processor
architecture. Systems are built with nodes—LIMs,
Line Interface Modules. An LIM can function as an
independent node or in combination with other LIMs
to form a single system. Since it is a single system,
management is always fully centralized. The concept is
flexible in regards to centralization versus decentralization;
both approaches can be adapted depending on specific
customer scenarios.
MX‑ONE™ offers all of the advanced telephony services
you can possibly expect from a modern communications
system. A rich set of features for both end-users and
operators provides all of the advantages of advanced
telephony features, such as modern directory searches
and message information. Executive secretarial services
are also available, including monitoring of mobile
extensions.
MX‑ONE™ caters to all customer scenarios—all-IP,
branch offices and geographically dispersed organizations.
Software only
In the latest version of MX‑ONE™ Telephony Server,
we have introduced a set of new features and system
enhancements:
Software only is available for use with general standard
servers.
• Support for SIP on both the user and trunk sides
• SUSE Linux Enterprise Server 10
SIP support can be used with SIP-compliant phones,
wired or WLAN.
• CPU, 3 GHz
• Network and server redundancy
Duplicated networks can be used for inter-LIM signaling,
and backup servers can be installed to take over duties of
defective servers.
• Security
Media encryption introduced
• Migration of existing MD110 installations to MX‑ONE™systems
Main server requirements:
• RAM, 1 GB
• Hard drive, 40 GB
Embedded Server Unit (ESU) and MX‑ONE™ Server
The Embedded Server Unit is an Ericsson-developed
solution available in two versions. The first version is
a blade server that is mainly used to upgrade existing
MD110/Telephony Switch installations. The second is a
19-inch-based version called MX‑ONE™ Server Unit.
MX‑ONE™ V.3.1 also offers integration with Microsoft®
LCS (Live Communications Server). An extension in
MX‑ONE™ can be fully visible on LCS clients, and featurewise, fully integrated. The user friendliness of mobile
extensions is considerably enhanced with integrated
support in the M600 and P990i.
Embedded Server Unit
MX‑ONE™ Telephony System
Building Blocks
The MX‑ONE™ Telephony System consists of two basic
components: the server and the media gateway. A server
and a media gateway can be combined to form either
a complete system or an LIM that is included in a large
multi-LIM system. So as to always provide cost-efficient
solutions, several hardware options have been developed.
Both the server and the media gateway are available with a
variety of options.
Server Options
This option is supplied as turnkey solution based on
HP ProLiant.
The MX‑ONE™ Server Unit can host a variety of
applications, such as D.N.A., applications for messaging
applications or any other application you may want to
install. The MX‑ONE™ Server Unit requires little space and
only 20 watts of power.
Main characteristics
– Intel® Prentium-M CPU, 1.4 GHz
– RAM, 512 MB
– Hard drive, 40 GB
– Same software as Telephony Server
Available in both a board version and a 19-inch rack
version
MX‑ONE™ Server
Media Gateways
Main technical characteristics:
• Intel® Xeon® 5140 Dual Core Processor, 2.33 GHz
• 1GB RAM, 72GB HDD, redundant fans
• Redundancy options:
– RAID hot-plug disk drives
– Redundant power supply
• Both the Linux operating system and Telephony Server
application software are installed and pre-configured.
The function of a media gateway is to form a bridge
between the IP and classic telecommunications worlds.
Media Gateway
The Media Gateway is a 19-inch, rack-mounted unit
enclosed in a 1U box, with the following features:
•
Telephony interfaces to IP networks (LAN), as well as
to public (PSTN/PLMN) and private (via QSIG) circuitswitched networks
• 72 IP gateways to PSTN/ISDN, IP extensions
• 8 T1/E1 network interfaces
• 4 POTS analog terminal interfaces to connect G3 fax
machines or emergency phones
MX‑ONE™ Compact SM
The Compact is a 2U box consisting of a 19-inch ESU
and a Media Gateway. It is a complete 700 line IPPBX
for IP or mobile extensions. MX‑ONE™ Compact SM is a
cost-efficient solution requiring little space and power—
just 45 watts.
• Digital signal processors (DSP) to convert non-IP voice
signals to IP and vice versa (Codecs)
Combined with an MX‑ONE™ Server Unit, a complete
system with applications is attained. Power consumption
is just 65 watts, providing considerable cost savings.
Server and media gateways can be combined in many
ways to provide cost-efficient solutions for a multitude of
scenarios.
Media Gateway Classic
The Media Gateway Classic is the preferred solution when
MX‑ONE™ is installed in an environment where both IP
and classic interfaces are present. It supports all classic
interfaces for the MD110: IP, ISDN, DECT and Mobile
Extension, both digital and analog.
Migration Scenarios
The Media Gateway Classic has the following
configuration:
MX‑ONE™ now also supports migration of existing
MD110 installations. Because only a limited number
of hardware boards need be replaced, most existing
hardware can be retained. Migration can proceed
at a cost-efficient pace, fully capitalizing on previous
investments. LIMs can now be distributed over IP
networks. Continued use of existing group switches, if
preferred, is supported in version 3.1.
• 32-channel, IP gateway resource boards for calls to
other LIMs and to IP extensions and trunks
Existing applications, such as D.N.A. or Netwise, are
compatible with MX‑ONE™.
The Media Gateway Classic uses the new 19-inch
mechanical standard.
Main characteristics:
• Digital extensions and trunks, IP, ISDN PRI and BRI,
ISDB S0, DECT and more
• Analog extension and trunks, CAS, E&M and more
• 480 extensions
CAPACITY OF MX‑ONE™ Telephony System
Maximum per system
3.1
Number of total users
50,000
Number of IP extensions
32,000
Number of non-IP extensions (Media Gateway Classic)
30,720
– Analog extensions in /Media Gateway Classic 4
30,720
– Digital extensions in Media Gateway Classic
30,720
Mobile extensions in Media Gateway
32,000
Number of trunk/tie-line channels (T1/E1)
E1 channels used in QSIG connection to Media Gateway
11,776/15,360
15,360
Technical data
(With or without existing group switch)
Supported standardsH.323v2 and 4
SIP
IPv4
DHCP, HTTP, Telnet, TFTP, FTP, SSH
Supported voice codecsG.711 with a-law and µ-law. G.729a, G.729ab with voice activity detection
(silence suppression & comfort noise generation).
G.723.1
Quality of ServiceDiffserv (RFC 2474) for trunks and extensions
IEEE802.1 p/Q extension-side only.
Compatible with cRTP header compression algorithms
Survivability
Automatic fallback to PSTN on WAN failure
TELEPHONY SERVER SOFTWARE 3.1 SPECIFICATION
Operator
CDR/SMDR records compatible with 3rd party accounting systems
Ericsson Dialog terminalsDialog 4187 analog phone with CLI
Dialog 4220, 4222, 4223 and 4225 digital phones*
Dialog 4420 and 4422 office IP phones*
Dialog 4425 Vision IP phone*
*See terminal datasheets for functionality with MX‑ONE™ Telephony System.
System managementTelephony system managed centrally by MX‑ONE™ Manager Telephony
System*
* See MX‑ONE™ Manager application datasheet for details on functions and features.
APPLICATIONS
Uses MX‑ONE™ Messaging* for voicemail, fax and unified messaging.
In MX-ONE Telephony system 3.1 the CMG application is used, with
D.N.A. for migrating customers.
Ericsson AB
SE-126 25 Stockholm
www.ericsson.com/enterprise
EN/LZT 102 3899-RC
© Ericsson AB, 2007
Subject to alterations without notice. Produced in Sweden on Eco-labeled paper
XGS ComPrint
Applications
Bogotá, Abril 14 de 2.008
Señores:
UNIVERSIDAD INDUSTRIAL DE SANTANDER
Atn: DIRECCIÓN DE CONTRATACIÓN Y PROYECTOS DE INVERSIÓN
Bucaramanga
Referencia: Observaciones a la evaluación técnica y económica de la LICITACIÓN PÚBLICA No. 022
de 2007 modernización tecnológica de la infraestructura de telecomunicaciones de la Universidad
Industrial de Santander.
Estimados señores:
En mi calidad de Representante Legal de la Firma World Service Ltda. Me permito solicitar muy
respetuosamente sea reconsiderada la decisión de la UIS de aceptar los requerimientos para los
switches tipo 3 (Ítem J) expresado en las evaluaciones técnicas y económicas del proponente
Assenda, en la licitación de la referencia. Consideramos que es importante colocar a consideración
del comité evaluador nuestros comentarios y observaciones los cuales nos permitimos transcribir
a continuación, dado que dos proponentes si presentamos los switches de acuerdo al nuevo
requerimiento:
OBSERVACIONES A LA EVALUACIÓN REALIZADAPOR LA UIS EN EL ITEM
RELACIONADO CON SWITCHES:
Muy respetuosamente queremos solicitar a la Universidad se sirvan revisar nuevamente la
explicación dada sobre la calificación dada a los proponentes Assenda y Colombia
telecomunicaciones relativa a los switches Multilayer tipo 3 (Item J), las razones que nos permiten
Número telefónico nacional: 01 8000 121261. e-mail cliente: [email protected]. Web: www.worldservice.com.co. Oficina principal - Bogotá: Carrera
10 Nº 24-55 Piso 10. Edificio WORLD SERVICE. Teléfono: 2863838. Sucursal Antioquia - Medellín: Carrera 43A # 16 SUR-47, Oficina 705, Edificio Panalpina, El
Poblado. Teléfono: 3140116 – 3140235. Sucursal Occidente - Cali. Avenida 5ª Norte Nº 21N-22 Oficina 701 Piso 7. Teléfono: 6600171. Sucursal Eje Cafetero –
Manizales. Calle 62 # 23 - 61, Edificio Torre Plaza 62 - Piso 4 - Oficina 402. Teléfono: 8859878. Sucursal Costa Atlántica – Barranquilla. Carrera. 58 No 75-158.
Oficina 406. Teléfono: 3681775. Sucursal Oriente – Bucaramanga. Carrera 36 No. 51-71. Oficina 207. Teléfono: 6575044
realizar esta sugerencia son: En la adenda # 5 la UIS fue clara en informar LA MODIFICACIÓN de lo
siguiente:(se anexa imagen de la sección de la adenda referida).
Es claro que no se requería que el ítem J incluyera el protocolo 802.3 AF, incluso en la descripción
del ítem en la misma adenda evidencia ese preliminar deseo: (se anexa imagen de la sección de la
adenda referida)
En forma posterior, la adenda # 6 del 25 de enero de 2008, modifica claramente ese
requerimiento en el numeral 9 en donde se lee textualmente que: “…Se modifican
especificaciones de los switches, literal H, I y J…”, y se incluye la nueva descripción del switche tipo
3 (Item J), en donde se observa el requerimiento de incluir la CAPACIDAD de soportar 802.3 AF. No
necesariamente entregar los switches con 15.4 watts por puerto. (Se anexa imagen página 10
adenda 6)
Lo anterior implica que los proponentes debíamos evidenciar y entregar en los ítems H e I el
cumplimiento de 15.4 watts por puerto, es decir adicionar fuente de poder externa para cumplir el
requerimiento. En el ítem J sólo la característica básica 803.AF, sin la fuente de poder externa.
Ninguno de los proponentes presentó reclamo sobre esta nueva funcionalidad, ninguno reclamó al
respecto, tuvimos el tiempo suficiente de leer y analizar, adicionalmente la adenda 7 de últimas
aclaraciones aparecida 6 días después (enero 31 de 2.008) no incluyó aclaración alguna sobre este
aspecto, por lo tanto y dadas las explicaciones anteriores, solicitamos muy respetuosamente a la
Universidad reconsiderar el cumplimiento de ese ítem para todos los proponentes. Dos de los
proponentes cumplimos el requerimiento de las adendas y sólo Assenda incumple presentando
para este ítem el switch 3com 4500G el cual no soporta 802.3 AF,
Cordialmente,
NICOLAS GARCIA ZAMORA
Representante Legal
c.c # 79-568.266 de Bogotá
Dirección: Carrera 10 # 24-55 Piso 10
PBX: 2863838
e-mail: [email protected]
Bogotá, Abril 14 de 2.008
Señores:
UNIVERSIDAD INDUSTRIAL DE SANTANDER
Atn: DIRECCIÓN DE CONTRATACIÓN Y PROYECTOS DE INVERSIÓN
Bucaramanga
Referencia: Observaciones a la evaluación técnica y económica de la LICITACIÓN PÚBLICA No. 022
de 2007 modernización tecnológica de la infraestructura de telecomunicaciones de la Universidad
Industrial de Santander.
Estimados señores:
En mi calidad de Representante Legal de la Firma World Service Ltda. Me permito solicitar muy
respetuosamente sean revisadas las evaluaciones técnicas y económicas de los proponentes
Assenda y Colombia Telecomunicaciones en la licitación de la referencia. Consideramos que es
importante colocar a consideración del comité evaluador nuestros comentarios y observaciones
los cuales nos permitimos transcribir a continuación:
OBSERVACIONES A LA EVALUACIÓN DE LA PROPUESTA DE ASSENDA S.A:
1.- Incumplimiento de requerimientos mínimos de sobrevivencia y disponibilidad: Nos
permitimos solicitar respetuosamente que la propuesta presentada por ASSENDA sea eliminada
por incumplimiento de especificaciones técnicas obligatorias exigidas por la Universidad dentro de
los pliegos de condiciones y adendas, las cuales a continuación nos permitimos recordar,
enfatizando en subrayado los aspectos que deseamos se verifiquen.
La UIS es muy clara y precisa al exigir en el pliego de condiciones volumen UNO página 3 se
cumpla que:
“…El Sistema de Telefonía debe contar con Servidores de Comunicación con redundancia ubicados
en el campus principal y servidores con supervivencia en cada una de las sedes tanto
Metropolitanas como Regionales de la UIS con el fin de asegurar la operación del sistema ante una
eventual falla de tal manera que los usuarios puedan comunicarse entre sí y también puedan
efectuar llamadas desde y hacia la Red Pública Telefónica Conmutada sin que exista una
dependencia del sitio central. Estos servidores se dimensionan de acuerdo con la totalidad de
usuarios en el Campus Principal, Sedes del Área Metropolitana y Sedes Regionales, etc, etc…”
Igualmente la Universidad en el volumen dos de especificaciones técnicas, página 5, numeral que
es ratificado en el formulario 4, es clara al exigir que DEBEN OBLIGATORIAMENTE cumplirse las
condiciones mínimas de : “...A. Servicios de Telefonía IP, Videoconferencia IP, Mensajería
Unificada y Equipos de Conmutación de datos Multilayer , en los numerales 13 y 14:
Por lo tanto, en forma respetuosa aseguramos que, la propuesta de ASSENDA incumple
totalmente estos requerimientos debido a las siguientes tres (3) razones fundamentales:
1.1- La pregunta que la Universidad debe realizarse en este punto es: ¿Qué sucedería con el
sistema de comunicaciones de la UIS, Campus Central, en caso de falla de una de las fuentes
de poder de un Gateway 650?. Otra razón de incumplimiento del proponente Assenda en el
diseño del Campus Central, se evidencia en lo relacionado con los dos (2) Gateways G650, los
cuales fueron configurados solamente con una fuente de poder cada uno, quiere decir que en
caso de daño de alguna fuente de poder de alguno de estos Gateways, todos los dispositivos y
funcionalidades gestionadas o administradas por el Gateway respectivo quedarían fuera de
servicio, incumpliendo con el requerimiento de disponibilidad y supervivencia exigidos en el
pliego. El proponente Assenda debió incluir para cada uno de los gateways fuente de poder
redundante en forma adicional, para un total de dos fuentes por Gateway 650, la cual se
conoce con el número de parte 700406135 G650 AC/DC PWR Supply 655A RHS. Para
información técnica ver folio 482 de la propuesta, por lo tanto no cumple los requerimientos
mínimos obligatorios del pliego de condiciones.
sistema de comunicaciones de la UIS, Sedes Metropolitanas y Regionales, en caso de falla de
una de las fuentes de poder de algún Gateway 350 ?. Adicionalmente, el diseño presentado
por Assenda no cumple el nivel de disponibilidad y supervivencia exigido para las regionales en
donde en caso de ocurrir alguna interrupción en el enlace de alguna sede con el Campus
Principal, la sede DEBERÁ seguir operando a través de la red PSTN para poder establecer
comunicación con el Campus Principal, lo anterior debido a que diseñaron TODAS las sedes
regionales con el Gateway G350 Stand Alone el cual NO soporta fuente de poder redundante
adicional, por obvias razones no fue incluida en el diseño, por lo tanto en caso de daño de
este elemento toda la sede queda incomunicada sin permitir ningún enlace o comunicación
con PSTN o campus central. Esta aseveración puede verificarse revisando ítem a ítem la
configuración folios 445 hasta folio 452 y no se evidencia en el catálogo técnico respectivo
(folios 176 y 448).
sistema de comunicaciones de la UIS, Sedes Metropolitanas y Regionales, en caso de
ausencia de fluido eléctrico o falta de corriente en una UPS ?. Igualmente el diseño de
Assenda para las regionales no cumple la disponibilidad y supervivencia, porque en caso de
ausencia de energía por fallas del fluido eléctrico local o falta de corriente en UPS local
quedaría totalmente incomunicada la regional. Para cada sede Metropolitana y regional,
debieron incluir (y no lo incluyeron) un módulo de Transferencia para permitir que la regional
tenga comunicación con la red pública, módulo 700394992 Emergency Transfer Panel G3RHS.
Esta aseveración puede verificarse revisando ítem a ítem la configuración folios 445 hasta
folio 452, y leyendo detenidamente el catálogo técnico respectivo.
Es claro que estos 3 numerales resumen el incumplimiento de los requerimientos mínimos en
cuanto a disponibilidad y sobrevivencia, ya que las respuestas dadas por el proponente en el
formulario técnico como, enterados y aceptados, no corresponden con la evidencia del listado de
partes que entregarían con su diseño, las cuales están descritas y relacionadas en los folios 445 al
452, razón por la cual respetuosamente aseveramos, es causal de rechazo de la propuesta.
2.- Incumplimiento diseño sede Facultad de salud: Para ésta sede la Universidad está solicitando
la cantidad de 124 extensiones. El proponente Assenda ofrece colocarlas en operación sobre un
Gateway 350 el cual soporta un crecimiento hasta 72 usuarios MÁXIMO, por lo tanto Assenda no
cumple el requerimiento exigido. Esto puede ser evidenciado en la configuración relacionada en el
folio 448 y leerse claramente en el catálogo técnico de este Gateway en el folio 176, donde en el
primer párrafo dice textualmente: “Gateway ideal de 8 hasta 72 extensiones”. Refirmándose esta
limitante en el catálogo incluido en el folio 403, Item: Scalability. Por lo tanto el diseño no cumple
los requerimientos mínimos para esta sede, siendo éste incumplimiento causal de rechazo de la
propuesta. No coincide la respuesta dada en el formulario técnico con el diseño detallado y listado
de partes de los folios 445 al 452, faltando de esta forma a la verdad.
3.- Incumplimiento en licenciamiento de usuarios sedes de la Facultad de Salud y Guatiguará.
Para estas sedes el proponente Assenda está ofreciendo un Bundle de licencias para 50 usuarios lo
cual se evidencia en los folios 447 al 452, incumpliendo de esta forma las cantidades mínimas que
exige la UIS para cada una de las sedes mencionadas, 69 y 124 respectivamente. En la
configuración ofrecida textualmente se lee: 50 user R5 CM Bundle S8300/S8400 SRVRS. No
coincide la respuesta dada en el formulario técnico con el diseño detallado y listado de partes de
los folios 445 al 452, faltando de esta forma a la verdad.
4.-Incumplimiento por no inclusión de Sede Barrancabermeja: La pregunta que la Universidad
debe realizarse en este punto es: ¿Qué elementos, partes, cantidades, equipos, software,
entregará el proponente Assenda para la Sede de la UIS en Barrancabermeja. En dónde está la
relación de partes y diseño de esta sede ?. El proponente Assenda en su oferta no incluyó el
diseño, configuración y cuadro de cantidades de la Sede Barrancabermeja, ver folios 445 al 452.
Por esta razón incumple el requerimiento de entregar en forma detallada el diseño de los
componentes y elementos para cada sede. Lo que ocasiona que:
La UIS no tiene cómo verificar qué elementos se entregarán para la sede de
Barrancabermeja, no se tiene criterio para conocer en forma precisa qué cantidades,
partes, opciones, licencias, hardware y software el proponente “diseñó” para esta
sede, a pesar de que “hay un valor” en su oferta económica, no detalla el
requerimiento obligatorio de relacionarlo, cuantificarlo en items y entregar el diseño
respectivo. El numeral 4.1.2.8 del volumen 1 es claro al exigir que: “…El proponente
deberá realizar y presentar en su propuesta un comparativo entre los requerimientos
de las características técnicas exigidas en el Volumen II - Especificaciones Técnicas,
versus las ofrecidas en su propuesta. La UIS verificará si los ofrecimientos cumplen con
lo exigido. El proponente deberá presentar en su propuesta un listado detallado con la
descripción, marca y modelo del equipo, materiales y accesorios ofrecidos. Lo anterior
también evita que la UIS evalúe el cumplimiento de cantidades y requerimientos para
cada regional exigidos en el numeral 1.2 Cuadro de requerimientos Volumen 2 página
3. Por lo tanto la propuesta de Assenda por este incumplimiento debe ser rechazada.
Adicionalmente Assenda no relaciona, ni entregó el número de parte o modelo de los
elementos a entregar ni para el Campus Central y tampoco para las regionales,
incumpliendo el requerimiento del numeral 4.1.2.8 del volumen 1.
5.- Incumplimiento en diseño y configuración correcta de teléfonos Avaya Wifi 3645: La
pregunta que la Universidad debe realizarse en este punto es: ¿Cómo funcionarán los
teléfonos Wifi 3645 en las sedes Metropolitanas y Regionales ?. El proponente Assenda está
ofertando los teléfonos Wifi de Avaya 3645 los cuales trabajan de la mano con un dispositivo
llamado AVAYA VOICE PRIORITY PROCESSOR, requisito obligatorio para que funcionen los
modelos 3641 y 3645 como se exige por parte del fabricante en el catálogo incluido en el folio
430, feature Wireless QoS. El proponente SOLO coloca este dispositivo para la sede del
Campus Central, y NO coloca, ni relaciona en su listado de partes este elemento en ninguna
sede desconociendo que la UIS fue clara al solicitar teléfonos Wifi en cada sede. El
proponente debió incluir un AVAYA VOICE PRIORITY PROCESSOR para cada sede dado que
ofertó en su propuesta teléfonos Wifi 3645, lo cual se evidencia del folio 445 al 452. Más aún,
este dispositivo es esencial cuando un diseño está basado en servidores stand alone para cada
sede.
Para evidenciar técnicamente esta aseveración técnica nos permitimos adjuntar dos
documentos técnicos de Avaya en donde se evidencian los requerimientos de los teléfonos
364::
a.- Whitepaper_3631_3641_3645.pdf
b.- Documento 3641/3645 IP Wireless Telephones
6.- No correspondencia de certificaciones entregadas en la propuesta con las relacionadas en
el formulario # 2: El pliego de condiciones exige que la información relacionada en los
formularios de experiencia del proponente, formulario 2, se acompañe con las certificaciones
expedidas por los clientes para evidenciar su cumplimiento. El proponente Assenda relaciona
en el formulario de experiencia una certificación con el Cliente Superintendencia Financiera de
Colombia (folio 501) la cual relaciona en el texto escrito en el formulario #2 que tiene como
fecha de inicio de contrato noviembre 30 de 2.007 y como fecha de finalización enero 28/08.
Sin embargo la entidad en mención emite una certificación de otro contrato, similar a la
relacionada, con fecha de inició el “30 dic 07” (sic) y terminación el próximo 20 dic 08 (sic),
igualmente la entidad reafirma, en documento contrato folio 505, que la fecha de terminación
será dic 08. Lo anterior implica que la certificación relacionada en el formulario #2 (folio 482)
no corresponde a la que se anexa como evidencia en la oferta, por lo cual sólo deben
evaluarse las dos certificaciones restantes descritas en dicho formulario. En conclusión,
proponente Assenda no anexó la certificación de la entidad Superintendencia Financiera de
Colombia relacionada en el formulario #2.
Para evidenciar esta no correspondencia de certificación, en forma adicional, con la
relacionada en el formulario #2, vemos que se lee claramente que la certificación expedida
por la entidad corresponde y hace referencia a un Servidor Avaya 8720 XL y el contrato
adjunto a la propuesta dice que corresponde a un servidor Avaya 8500 (folio 502).
Estas son las razones de peso, que respetuosamente colocamos como evidencia para su
evaluación, razones suficientemente claras para rechazar esta certificación y la elaboración
incorrecta del formulario #2.
No obstante si se quisiera tomar todo lo anterior como error en la transcripción de fechas y
modelos de servidores (en tres partes: formulario #2, contrato y certificación), es claro y
evidente que el documento expedido por la entidad con fecha 1 de febrero de 2.008 , tan sólo
4 días antes del cierre de la licitación 022, dice textualmente: “…que se encuentra en
adecuaciones para la instalación y configuración…”, es decir que certifica que ni siquiera se ha
iniciado la instalación, sería un proyecto apenas a implementarse durante todo el 2008 y
terminaría en diciembre 20, a esa fecha la implementación y puesta en producción del
proyecto de la UIS llevaría cerca de 5 meses en operación, adicionalmente el proceso de
instalación hace parte del objeto de la licitación y no la simple proveeduría, lo cual da como
resultante una certificación carente de uno de los requerimientos del objeto de la licitación,
adicionalmente no permite a la UIS evaluar qué porcentaje se ha ejecutado, por lo tanto
tampoco sería un documento válido para calificación y evaluación en esta licitación.
Quiere decir que el proponente incumple el puntaje mínimo exigido para certificar
experiencia, por lo tanto su propuesta, respetuosamente solicitamos, sea rechazada y
eliminada.
7.- Incumplimiento por no inclusión de respaldo de fabricantes en las garantías y
actualización de software: La Universidad en la adenda #6 es clara y precisa en el numeral 3
que dice textualmente:”… Se modifica el quinto párrafo del numeral 4.1.2.4. Garantía mínima,
del volumen I de los pliegos de condiciones, así: El Contratista estará respaldado por los
fabricantes, así como la garantía del mismo. Este respaldo deberá ser acreditado mediante
carta del fabricante en la que éste respalde la garantía sobre el Hardware (servidor, switches,
gateways y telefónos) y Software con sus respectivas actualizaciones durante todo el tiempo
de la garantía ofrecida…”. El proponente Assenda no adjunta ni acredita las cartas de respaldo
de actualización (updates y upgrades) para el software de switches y tarificador telefónico. En
la carta firmada por su representante legal y adjunta en el folio 582 se afirma que se cuenta
con el respaldo para garantía y actualización de software por parte de los proveedores Avaya,
3com y Calltech, pero en ninguna parte se adjunta las certificaciones respectivas de los
fabricantes 3com y Calltech en donde se avalen los 51 meses de garantía y actualización,
exigidas por la UIS. En la sección correspondiente a software se adicionaron copias idénticas a
garantías de hardware ya incluidas, inclusive la certificación de hardware de 3com (folio 576)
condiciona la entrega del repuesto 30-45 días hábiles después de ser entregada la parte
dañada a su centro logístico (a propósito, ubicado en Bogotá). De otra parte las certificaciones
entregadas por 3com condicionan la propuesta ya que en letra menuda dice claramente que:
“… Todas las políticas de garantía están sujetas a cambio sin previo aviso…”
Igualmente el fabricante de software Calltech (Tarificador telefónico) no menciona la
autorización del proponente en otorgar los 51 meses de garantía e inclusión de actualizaciones
de software.
Dado lo anterior el proponente Assenda no evidencia el requerimiento de las certificaciones y
respaldo de los fabricantes 3com y Calltech en software y ACTUALIZACION DE SOFTWARE
respaldados por los mismos, luego la calificación y puntaje adicional relativo a los meses
adicionales tampoco sería válido, además de ser causal de rechazo de la propuesta la ausencia
de los documentos mencionados. No se evidencia la inclusión de las cartas de respaldo de los
fabricantes en los folios 560 al 582 y en ninguna otra parte de la propuesta.
8.- Incumplimiento diseño de Switches. El proponente Assenda en las respuestas técnicas del
formulario # 4, relacionadas con los switches, literales H, I, J del volumen 2, no evidencia qué
modelos específicos de estos equipos entregará a la Universidad, sólo menciona la familia
4500 en forma general, adicionalmente no evidencia cuál fuente de poder externa colocará
para cada switch, los catálogos relacionados con estos productos en los folios 416 al 428 no
especifican la adición de fuente externa. Para información de la UIS nos permitimos,
respetuosamente informar que, estos switches usan fuentes de poder externa que NO son
marca 3com, son fabricadas, entre otros proveedores, por EATON POWERWARE. Lo anterior
se debe a que los switches 3com sólo alimentan energía hasta 150 watts en switches PWR de
24 puertos y 320 watts para switches PWR de 48 puertos, requiriendo necesariamente de una
fuente adicional para llegar a 15.4 watts por puerto para los switches solicitados. La
Universidad a futuro no sólo conectará dispositivos telefónicos en estos switches sino que
requerirá colocar la nueva generación de dispositivos SIP de comunicación que requieren 15.4
watts de potencia como mínimo, como por ejemplo teléfonos con video. Dado lo anterior, la
UIS debe asegurar el soporte correcto de la fuente de poder externa a los switches PoE, las
cuales deben ser adquiridas a otro fabricante por el proponente Assenda, razón por lo cual
debió anexar las certificaciones de distribución, iso, garantía, proveeduría de repuestos de
POWERWARE, catálogos de evidencia del producto, entre otros documentos.
El argumento presentado por el proponente en su aclaración indicando que la potencia
requerida por los teléfonos Avaya es menor a 15.4 watts, no es suficiente argumento ya que la
UIS fue clara en el requerimiento mínimo de 15.4 watts por puerto. Limitarse,
respetuosamente lo decimos, a informar que: “…cumplimos…” (SIC) sin evidenciar lo explicado
anteriormente es muestra clara de incumplimiento.
OBSERVACIONES A LA EVALUACIÓN DE LA PROPUESTA DE COLOMBIA
TELECOMUNICACIONES:
Muy respetuosamente solicitamos adicionar a los incumplimientos de la propuesta de Colombia
Telecomunicaciones las siguientes observaciones que colocamos a su consideración:
1.- No incluyó en ninguna parte de su pliego la evidencia de cumplimiento, certificaciones de
distribución, garantías de tarificador telefónico (Eagle Control), softconsole (Counter Path). Ver
anexo 8 y 10, folio 143.
2.- Adicionalmente no evidencia en los Switches tipo H, I la descripción de la fuente adicional
requerida para operación de los switches cumpliendo 15.4 watts por puerto.
3.- No se observa evidencia del cronograma de trabajo para la implementación de la solución.
4.- La Carta de Garantía de Switches explica claramente que se cuenta su tiempo a partir de salida
de fábrica de los equipos, luego el tiempo ofertado por el proponente es menor a 3 años y no de 3
años como afirma en sus respuestas.
Cordialmente,
NICOLAS GARCIA ZAMORA
Representante Legal
c.c # 79-568.266 de Bogotá
Dirección: Carrera 10 # 24-55 Piso 10
PBX: 2863838
e-mail: [email protected]
FACT
SHEET
3641/3645
IP Wireless Telephones
Overview
The Avaya 3641 and 3645 IP wireless telephones are
designed for organizations that want the convenience of
wireless communications and the benefits of leveraging
IP‑based converged communications solutions. These wireless
telephones connect to your LAN, simplifying the management
of your communications infrastructure. Wireless voice solutions
enable users to be available to customers and co-workers thus
improving productivity.
Avaya 3641
IP Wireless Telephone
Avaya 3645
Capabilities
The Avaya 3641 and 3645 IP wireless telephones are
the user and seals out background noise. Like the 3641,
designed to meet the business needs of both office and
the 3645 IP wireless telephone is equipped with a back-
industrial environments. While working away from your
lit keypad and large display allowing for easy use. Built-
desk, you can make and receive phone calls (including
in speakerphone, headset compatibility, and extended
Caller ID), place calls on hold, establish conference
battery options boost efficiency and extend accessibility.
calls, and check for messages, just to name a few. The
navigation keys provide the user with easy and efficient
The 3641 and 3645 IP wireless telephones support
access to additional capabilities through the display.
the following:
Ideal in any work environment, the 3641 IP wireless
telephone addresses the day-to-day rigors of the mobile
user across many industries with back-lit keypad and
large display. It is lightweight yet rugged in design
making it a reliable option being resistant to dust,
shock, and liquid damage. The convenience of the
built-in speakerphone and headset compatibility
increase productivity and responsiveness for the user.
The extended battery options increase accessibility by
providing 24 hour operation.
The 3645 IP wireless telephone is designed for the
industrial environment with its push-to-talk capability
eliminating the need for two-way radios appropriate
• 128 x 96 backlit display with icons and line-status
indicators
• Standard Battery – 4 hours talk time, 80 hours
standby time
—Optional Extended Battery – 6 hours talk time,
120 hours standby time
—Optional Ultra-Extended Battery – 8 hours talk time,
160 hours standby time
• 802.11a, 802.11b, and 802.11g standardcompatible
• Dust, shock and liquid damage resistant
• Headset jack (2.5mm)
for work groups that are dispersed throughout an
• Speakerphone
environment. The larger earpiece provides comfort for
• Audible and vibrating alerting
Model
• 3641 / 3645
Format
• 802.11a
• 802.11b
• 802.11g
Display
128 x 90
Dimensions
3641
3645
• 5.4” x 2.0” x 0.9”
• 5.7” x 2.2” x 0.9”
• 13.72cm x 5.08cm x 2.29cm
• 14.48cm x 5.59cm x 2.29cm
Weight
• 3.9 – 4.8 ounces (battery pack dependent)
• 110.57g - 136.08g (battery pack dependent)
Wireless QoS
• Avaya Voice Priority Processor (VPP), Wi-Fi Multimedia (WMM)
Access Points
• Meru Networks Wireless LAN System with AP150
• Aruba Mobility Controllers 200, 800, 2400, 6000 with AP41, 60, 61, 65, 70
• Some access points from 3COM, Alcatel-Lucent, BelAir, bluesocket, Cisco, Colubris
Networks, Extreme, Nortel, Siemens, Motorola, and Trapeze are also supported.
Avaya 3641
For a complete list of supported AP, visit support.avaya.com.
Wireless Security
• Wi-Fi Protected Access (WPA) and WPA2 with Pre-Shared Key (PSK)
• Standard WEP 40-bit and 128-bit
Management
• DHCP, TFTP
Durability
• IP53 certified for resistance to dust and liquid resistance
• MIL 810F Proc IV 516.5 for shock resistance
Operating Temperatur
• 0-50º C
System Compatibility
• Avaya IP Office R4.0
• Communication Manager R2.2 or Greater
Available Headsets
• NAR: Supra Mon NC RF (Material Code 407713718)
• EMEA: Supra Elite Mon NC (Material Code 700413933) or Supra Elite Bi NC
(Material Code 700413958)
Learn More
For more information, contact an Avaya Authorized BusinessPartner or visit avaya.com.
Avaya 3645
About Avaya
Avaya delivers Intelligent
Unified Communications, Contact
Communications solutions that
Centers and Communications
help companies transform their
Enabled Business Processes.
businesses to achieve market-
Avaya Global Services provides
place advantage. More than
comprehensive service and
1 million businesses worldwide,
support for companies, small
including more than 90 percent
to large. For more information
of the FORTUNE 500®, use
visit the Avaya Web site:
Avaya solutions for IP Telephony,
http://www.avaya.com.
© 2007 Avaya Inc. All Rights Reserved.
Avaya and the Avaya Logo are trademarks of Avaya Inc. and may be registered in certain jurisdictions.
All trademarks identified by the ®, SM or ™ are registered trademarks, service marks or trademarks,
respectively, of Avaya Inc. FORTUNE 500 is a registered trademark of Time Inc. All other trademarks
are the property of their respective owners.
07/07 • SB3431-01
avaya.com
White Paper
Avaya Wireless Telephones 3631 3641 3645
Whitepaper about similarities and differences
An
Installation and Configuration Overview
Version 1.1
Summary
This document gives a short summary of the most essential topics, necessary to prepare and configure the WLAN environment and the Avaya wireless telephones (WTS) connected to a Communications Manager (CM). To make the readability easier tables are used to achieve a faster overview of
the similarities and the differences between the handset series 3631 and 3641/3645.
Please note, that this document does not make the manuals (covered in the reference section of this
document) superfluous.
White Paper
Contents
1 Overview
1.1
1.2
1.3
Avaya wireless phone characteristics
General WLAN environment
Add on WLAN device - Avaya Voice Priority Processor
2 Installation and Configuration
2.1
CM Configuration
2.2
Network Configuration
2.2.1
Avaya 3631
2.2.2
Avaya 3641/3645
2.3
DHCP
3 Phone Configuration
3.1.1
Differences Between 3631 and 3641/3645 handsets
3.1.2
Avaya 3631 Configuration
3.1.3
Avaya 3641/3645 Configuration
3.1.4
Avaya Voice Priority Processor (AVPP)
3.1.5
TFTP Server
4
4
5
5
6
6
6
6
6
7
7
7
8
9
9
9
4 Software Upgrade
4.1
Software Upgrade Options
4.1.1
Avaya 3631 Software Upgrade
4.1.2
Avaya 3641/3645 Software Upgrade
10
10
10
10
5 FAQ
10
6 References
11
© Copyright 2006 Avaya Corporation. All rights reserved
Page 2
White Paper
History
Date
Version
Author
Status
Changes
02/27/2007
0.1
Dziumbla
Draft
Initial Draft
03/02/2007
1.0
Dziumbla
Version
First reviewed version
03/13/2007
1.1
Dziumbla
Version
Document name has been changed, additional comments included.
Abbreviations
ACM
Avaya Communications Manager
AP
(WLAN) Access Point
AVPP
Avaya Voice Priority Processor (Spectralink SVP)
CM
Communications Manager
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System
FTP
File Transfer Protocol
HTTP
HyperText Transfer Protocol
IP
Internet Protocol
NTP
Network Time Protocol
OAI
(Spectralink Open Application Interface)
PTT
Push to Talk
QoS
Quality of Service
SSID
Service Set IDentification
SVP
Spectralink Voice Processor (Avaya AVPP)
TFTP
Trivial File Transfer Protocol
USB
Universal Serial Bus
VIEW
Voice Interoperability for Enterprise Wireless Certified
VLAN
Virtual Local Area Network
WLAN
Wireless Local Area Network
WPA
Wireless fidelity (WI-FI) Protected Access
WPA2
Wireless fidelity (WI-FI) Protected Access version 2
WTS
Wireless Telephone (Avaya 36... series)
WTS
Wireless Telephone System
Page 3
White Paper
Overview
1.1 Avaya wireless phone characteristics
The main characteristics of the new Avaya wireless handsets are given in table 1:
Avaya 3631
Avaya 3641
Avaya 3645
Standards-based phone:
- 802.11 b/g radio
- 2.4 & 5 GHz Wi-Fi b/g, a radio - 2.4 & 5 GHz Wi-Fi b/g, a radio
- 802.11i security
- 802.11i security
- 802.11i security
- 802.11e QoS
- 802.11e QoS
- 802.11e QoS
H.323 protocol
H.323 protocol
H.323 protocol
Color display
Improved user interface
Improved user interface
9600-style user interface
Lightweight form factor
Lightweight form factor
- 802.11d country support
1
Shared accessories 1)
Shared accessories )
Push-to-talk (PTT)
– 24 channels
+ priority channel
Larger ear cup, larger fonts
Rubberized sized grips
table 1: Avaya wireless telephone characteristics
1
) For the 3641/3645 series handsets a great variety of accessories are available including installation
support as well as additional batteries or other accessories like clips, carrying cases etc.
table 2 gives an example of the different charger options
Single Charger
In-charger dialing
Dual Charger
Quad Charger
In-charger dialing
LED indicators
LED indicator (for standalone
battery)
Designed for easy Battery Pack
removal
Wall mount with cable routing
removal
USB port for software updates
table 2: Avaya 3641/3645 Charger Options
In comparison with this there are two different chargers available for the 3631 phones (table 3).
Single Charger
In-charger dialing
Dual Charger
In-charger dialing
LED indicator (for standalone
battery)
removal
table 3: Avaya 3631 Charger Options
Page 4
White Paper
1.2 General WLAN environment
The Avaya wireless telephones need a correctly configured WLAN environment. This means using
proper channel allocation – the strongest Access Point (AP) should be on different channel than the
next strongest AP – and the use of a pre-installation/post-installation Site Survey to certify installation.
Depending on the planned Avaya phone type there are different requirements which should be met to
avoid disturbances in the final system (table 4).
AP Recommendations
Avaya 3631
Avaya 3641/3645
Set phone to same transmit
power setting as AP
Set phone to same transmit
power setting as AP
Minimum recommended signal Minimum recommended signal
strength -70dBm
strength -70dBm
-60dBm minimum for high data -60dBm minimum for high data
rate
rate
AVPP
802.11e support
Must support SVP prioritzation
-
AP should be Spectralink View
certified 1
-
mandatory
table 4: WLAN environment
1.3 Add on WLAN device - Avaya Voice Priority Processor
The Avaya Voice Priority Processor (AVPP) is an Ethernet LAN device that works with the AP to provide QoS on the wireless LAN. Voice packets and call signalling to and from the Avaya WTs are intercepted by the AVPP and encapsulated for prioritization as they are routed to and from an IP telephony
server or gateway. The main characteristics are
•
an Ethernet LAN appliance that works with the AP to provide QoS on the wireless LAN
•
all packets to and from the 3641/3645 Wireless IP Telephones are sent through the Avaya Voice
Priority Processor and are encapsulated for prioritization as they are routed to and from the
3641/3645 handsets.
• AVPP also provides bandwidth admission control and aids telephones in power management
The AVPP may also be referred to as SVP (Spectralink Voice Processor). This is the same device
(hardware & software) with Spectralink logo and labels – may be found especially in older installations.
fig. 1: AVPP
Note this device is required for the Avaya 3641/3645 handsets only.
1
Voice Interoperability for Enterprise Wireless (VIEW) Certification Program
The SpectraLink VIEW Certification Program is a partner program designed to ensure interoperability and maximum performance for enterprise Wi-Fi infrastructure products that support NetLink Wireless Telephones. See also:
http://www.spectralink.com/resources/wifi_compatibility.jsp
Page 5
White Paper
2 Installation and Configuration
2.1 CM Configuration
Details of the Communication Manager (CM) configuration are given below.
Avaya 3631
Avaya 3641/3645
certified with CM 3.0, 3.1. CM 4.0 actually not supported but planned to do.
certified with CM 3.0, 3.1. CM 4.0 actually not supported but planned to do.
Create CM station record for phone
through ‘add station’ command
Create CM station record for phone
through ‘add station’ command
Must enter 4620 as station type
Must enter 4612 as station type
May configure as primary extension for May configure as primary extension for
user or as bridged extension off of desk- user or as bridged extension off of
top phone
desktop phone
Media stream may be en-crypted using
AES or AEA
Codec set used for phone must allow
media streaming without encryption
For bridged extension
For bridged extension
Set “Message Lamp Ext” to the extension of the associated desk station.
Set “Message Lamp Ext” to the extension of the associated desk station.
Set “Bridged Call Alerting”
to “y.”
Set “Bridged Call Alerting”
to “y.”
Set “Auto Select Any Idle Appearance”
to “y.”
Set “Auto Select Any Idle Appearance” to “y.”
For Button Assignments, create
bridged appearances to the line appearances on the desk station.
For Button Assignments, create
bridged appearances to the line appearances on the desk station.
table 5: CM Configuration
2.2 Network Configuration
The main network configuration requirements are
2.2.1 Avaya 3631
•
Call Server HTTP and FTP Server may be on a different subnet
•
The wireless LAN should be placed on a separate VLAN or subnet to reduce the effects of
broadcast and multicast traffic from devices in other network segments
2.2.2 Avaya 3641/3645
•
The Avaya Voice Priority Processor, all access points, and all wireless telephones should be
on the same subnet. Timing requirements for traffic between phones and AVPP are more critical than normal VoIP timing requirements.
•
Call Server and TFTP Server may be on a different subnet
•
IP multicasting must be enabled on the subnet used for the 3645 Telephones (to enable Pushto-Talk) and AVPP Server.
•
The wireless LAN should be placed on a separate VLAN or subnet to reduce the effects of
broadcast and multicast traffic from devices in other network segments
Page 6
White Paper
2.3 DHCP
The 3631, 3641 and 3645 supports DHCP for IP address assignment and configuration of other telephone options as described in detail below.
DHCP
Option
Meaning
Avaya 3631
Avaya 3641/3645
1
Subnet Mask
yes
yes
3
Default Gateway
yes
yes
6
DNS Server
yes
yes
7
Syslog Server
no
yes
15
Domain Name
yes
yes
42
Network Time Protocol Server
no
yes (if available)
66
TFTP Server
no
yes
151
Avaya Voice Priority Processor
no
yes
152
NL OAI Gateway
no
yes (if available)
176
Avaya Specific Options (MCIPADD, MCPORT)
yes (optional)
yes
242
Avaya Specific Options (MCIPADD, MCPORT)
yes (default)
no
table 6: DHCP Options supported
3 Phone Configuration
3.1.1 Differences Between 3631 and 3641/3645 handsets
The main differences between the two series of wireless telephones (WTS) are
3631:
•
Supports 802.1X (WPA Enterprise/WPA2 Enterprise)
•
Has a color display
•
Has multiple built-in applications (browser, calendar, call log, alarm clock, calculator)
•
Configured as 4620 phone type in CM
•
Targeted at general office environment
•
No AVPP server requirement
3641/3645:
•
Supports 802.11a or 802.11bg operation
•
Supports Push-To-Talk (3645 only)
•
Open Applications Interface (OAI) for vertical application support
•
Requires AVPP/SVP server
•
Configured as 4612 phone type in CM
• Targeted at general office and high-density environments
Because of the different configuration philosophies of the handsets
•
3631 is based on a config file (same format as wired Avaya IP phones) and uses a SIM-card
• 3641/3645 uses special configuration hardware and software (no SIM-card)
each of the different configuration procedures is described below in its own chapter.
Page 7
White Paper
3.1.2 Avaya 3631 Configuration
3.1.2.1 Minimum Configuration Data
The following data is required for associating with an AP, accessing the DHCP server, and the accessing file server to obtain the 46xxsettings file. This information may be entered directly into the phone
through its menu interface, or downloaded to the phone via the 46xxsetttings file. :
• SSID (WTSSIDP[1-3])
• Security Type (WTSECP[1-3])
• Encryption Type (ENCRYPTP[1-3])
• Encryption Key (WTKEYP[1-3])
• EAP Type (EAPTYPEP[1-3])—only required for Security Types, WPA-802.1X or WPA2802.1X (actually supported EAP Types: TLS, LEAP, PEAP-GTC, PEAP-MSCHAPV2, TTLSCHAP, TTLS-MD5, TTLS-MSCHAP, TTLS-MSCHAPV2).
• Country (WTREGDOM)—only required if outside US
• DHCP SSON—only required if using value other than 242
3.1.2.2 Downloading 46xxsettings File via USB
The 3631 telephone supports downloading of the 46xxsetings.txt file from a Windows PC that is connected to the phone via a USB cable. This is in addition to downloading the file over the air from an
HTTP server.
A single PC can be connected to one or multiple phones simultaneously. Connecting to multiple
phones requires a USB hub and multiple USB cables.
Connect Samsung USB Debug Cable with the Phone for USB Operations
3631 Phone
USB HUB
USB Cable
Windows PC
Samsung USB
Debug Cable
Samsung USB
Debug Cable
Note: Only a Samsung cable with an 18-pin connector can be used to support USB operations on the
3631 telephone; it should be ordered separately.
For further details refer to [1]
Page 8
White Paper
3.1.3 Avaya 3641/3645 Configuration
For the Avaya 3641/3645 handsets a correctly configured AVPP is mandatory. Refer to [2]] for configuration details.
3.1.3.1 Minimum Configuration Data
For WLAN settings the following data should be entered manually via admin menue or through the
Handset Administration Tool running on a Windows PC.
• Telephony Protocol (via admin menu only, set to 033)
• ESSID
• Security Type (none/WEP/WPA/WPA2)
• Encryption Key
• Regulatory Domain (via admin menu only2)
• 802.11 configuration (a/b/g)
• Transmit power (recommended)
For network purposes the data below should be entered manually, through Handset Administration
Tool, or passed by DHCP.
•
•
•
•
•
•
•
•
•
•
IP Address
Subnet Mask
Default Gateway IP address
TFTP Server IP address
AVPP Server IP address
Call Server IP address
Call Server Port
OAI Gateway IP address (optional)
Syslog Server IP address (optional)
Time Server IP address (optional)
3.1.4 Avaya Voice Priority Processor (AVPP)
To support Avaya 3641/3645 handsets the requirements for the AVPP are
•
•
Must be running firmware version 17x.028 or later.
the Avaya Voice Priority Processor must be statically configured to have a permanent IP address.
• must be on the same subnet as the Wireless Telephones
For further information on how to configure the AVPP refer to [2].
3.1.5 TFTP Server
It is strongly suggested to use the Microsoft or 3COM TFTP server, which supports a retransmission if
any error occurs.
The 3COM TFTP server is available as:
http://support.3com.com/software/utilities_for_windows_32_bit.htm
here use “3CDaemons ver. 2.0 rev.10 (3cdv2r10.zip).
2
Selects Network Config option, then Reg Domain option. Use Line button to set to proper domain
(01 for US, 02 for EU).
Page 9
White Paper
4 Software Upgrade
4.1 Software Upgrade Options
4.1.1 Avaya 3631 Software Upgrade
The following software upgrade procedure may be used with the Avaya 3631 handset :
•
Independent upgrade program, automatically invoked after 46xxsettings file download
•
Phone downloads a new image from HTTP server, erases current image from memory, and
writes new image
•
Program first downloads upgrade configuration file. After receiving upgrade file, phone checks
its current version with version info of upgrade file
•
If versions are different, phone downloads binary files in order according to upgrade file list. If
versions are same, upgrade does not execute.
•
If there is a problem during downloading (network issue, disconnection, no server response),
phone reboots itself and attempts upgrade again. Process repeats until successful.
4.1.2 Avaya 3641/3645 Software Upgrade
The Avaya 3641/3645 handset may be upgraded using one of the methods mentioned below:
•
Manual upgrade from PC
o Phone placed in Dual Charger
o Connected to PC via USB cable
o Files downloaded via Handset Administration Tool
•
Automatic, over-the-air upgrade via TFTP server
o Phones upgraded automatically during startup
5 FAQ
After power on, phones are going into an restart loop.
Answer: Sometimes the AVPP does not work correctly. Reset the AVPP using the reset command via
a Telnet session. A reset by powering off and on the AVPP does not solve the problem.
If this does not help, check the network for a firewall between AVPP and CM. Check for any traffic
between AVPP and CM blocked by the firewall.
After upgrading a 3641/3645 handset to software version 117.013, the handset does not work
Answer: With this software version it is first-time mandatory to set the “regulatory domain”. The procedure to specify regulatory domain is simple. User logs in as admin on phone. Selects Network Config option, then Reg Domain option. Use Line button to set to proper domain (01 for US, 02 for EU).
There is a new AVPP software on the TFTP server, but the AVPP does not upgrade.
Answer: Check whether the filenames are correct (note: the filenames are case sensitive)
How to change the AVPP Software
Answer: Normally during startup the AVPP reads its software from the TFTP-Server’s working directory if no error occurs. In the case of any issue the AVPP reads his software from the TFTP-Server
working directory’s subdirectory “Avaya”. So it is mandatory to copy the new AVPP software to both
directories.
Page 10
White Paper
6 References
[1]
[2]
[3]
3631 Wireless Telephone Administrator Guide
Avaya Voice Priority Processor Installation, Setup, and Administration
Avaya 3641/3645 Wireless Ip Telephone and Accessories Guide
Page 11

Primera parte

Transcripción

Documentos relacionados

Fabric Connect, tu número 10

“La firma Durán-Sindreu Asesores Legales y Tributarios despliega

MARCATRON CB Características Requerimientos

Un caso de negocios para soluciones móviles

PROVEEDOR DESCRIPCION