Provisionar Teléfonos Polycom VVX (Parte 1: Configuración del Servidor FTP y los parametros DHCP)

Posted on Actualizado enn

Quizás este no sea uno de los artículos del blog más llamativo técnicamente, pero si es cierto que la primera vez que te “topas” con un aprovisionamiento de teléfonos Polycom para Lync, puedes tener muchos quebraderos de cabeza, esto me ocurrió a mí a la hora de desplegar 600 teléfonos del modelo VVX410 y 600 en un cliente.

Hay innumerables páginas y blogs que explican cómo provisionar estos teléfonos, como es el blog de Jeff, un referente en el mundo Polycom y Lync/Skype4B. Pero pocas quizás que cuenten todo el proceso, tanto la configuración del Servidor FTP, la configuración del DHCP, las opciones del fichero de configuración e incluso tareas de mantenimiento como es actualizar el dispositivo o mandar un reinicio de forma remota, por ello, he dividido todo el proceso en los siguiente artículos que iré publicando


  • Parte 1: Configuración del Servidor FTP y los parámetros DHCP.
  • Parte 2: Configuración DHCP para Lync Phone Edition.
  • Parte 3: Opciones del fichero de configuración
  • Parte 4: Script para cambiar el PIN a los usuarios
  • Parte 5: Reiniciar los dispositivos de forma remota

Además no solo explicaré el proceso, si no también contare mi experiencia con un despliegue.


Preparar el Servidor FTP de aprovisionamiento

Para provisionar los teléfonos necesitaremos montar un servidor FTP al cual los teléfonos se conectaran para descargar su fichero de configuración e incluso desde el cual podemos lanzar una actualización de versión para los mismos.

Hay infinidad de servidores FTP, muchos conocidos y famosos como “filezilla” pero yo en mi caso utilicé un servidor FTP/TFTP que usaba en mis años de técnico Networking para actualizar la versión de los Switches Avaya/Nortel, este servidor se llama “3CDaemon“.

Pero independientemente de la elección por un servidor FTP u otro, lo más importante y que hay que tener en cuenta es que, los teléfonos Polycom VVX tienen por defecto las siguientes credenciales:

User: PlcmSpIp
Password: PlcmSpIp

Con lo cual, el servidor FTP que usemos debe permitir poder añadir un usuario con el mismo usuario y contraseña. Algunos de ellos por políticas de seguridad de password no lo permite.

Configurar el Servidor FTP

Con el servidor FTP instalado, lo arrancamos y entramos en la configuración.

ftp1

Desde la configuración añadiremos el usuario “PlcmSpIp” en “Profile Name”

ftp2

A continuación, pulsaremos en “Set/Change Password” para añadir la password

ftp3

Ya tenemos el usuario, ahora le daremos todos los permisos

ftp4

Y seguidamente, seleccionamos el directorio donde el teléfono descargara su fichero de configuración, en este caso he llamado a la carpeta “UCS”

ftp5

Por ultimo, aplicamos los cambios y salvamos la configuración

ftp6

Probar el FTP

Una vez configurado el FTP, podremos probarlo lanzando una petición desde nuestro interprete de comandos lanzando “ftp ucs.mrlync.com” y poniendo el usuario y la clave

probar ftp

** Una vez configurado, instalado y probado el servidor de aprovisionamiento, recomiendo de momento dejar parado el FTP y levantarlo cuando tengamos todo el despliegue preparado

Parar FTP

Descargar el contenido de la carpeta UCS

A continuación vamos a descargar el paquete de software del teléfono que será el contenido que incluiremos en nuestra carpeta UCS, previamente asociada al FTP.

Para descargar los paquetes de software de Polycom podemos hacerlo desde el siguiente enlace

http://downloads.polycom.com/voice/voip/uc_sw_releases_matrix.html

Yo siempre recomiendo inicialmente descargar la misma versión que los teléfonos tienen cargada localmente, ya habrá tiempo de actualizarla. En mi caso la versión por defecto que traían los teléfonos era la 5.3.1:

ucs

Una vez identificada la versión, descargar la versión “Split” y seguidamente descomprimir todo el contenido en la carpeta UCS

Configuración del DHCP para modelos VVX

Una vez tenemos nuestro Servidor FTP preparado, vamos a configurar los parámetros del DHCP que el teléfono “necesita” para saber cúal es su servidor de aprovisionamiento.

Primero, si no lo tenemos dar de alta en el DNS el nombre de nuestro servidor. En mi caso el servidor se llamara ucs.mrlync.com.

Si no lo tenemos, agregamos la opción 160 del DHCP con el nombre “UCS Boot Server

Una vez tenemos nuestra opción 160 en el DHCP, ponemos como valor de la cadena la dirección de nuestro FTP “ftp://ucs.mrlync.com”

Captura1

Realizamos lo mismo con la opción 66 del DHCP añadiendo la dirección del DHCP

Captura2

Otra opción que debemos configurar, es el servidor de tiempo NTP, esto es fundamental, normalmente es la dirección IP de nuestro Domain Controller.

Captura3

Estos son los parámetros configurables para que el teléfono VVX conozca su servidor de aprovisionamiento. Existe otro valor, que es el “Time Offset“, donde le daremos al teléfono la hora local. En este caso yo lo configuro en fichero de configuración que distribuiremos luego a los teléfonos.

Una vez hayamos configurado los parámetros en el DHCP daremos un reinicio al teléfono con el FTP parado y una vez reiniciado veremos que en el teléfono debe aparecer la dirección de nuestro servidor DHCP la cual está cogiendo de las opciones DHCP que hemos configurado.

mainScreen

Para que los teléfonos VVX se puedan registrar en Lync, hay que aprovisionarles de un certificado para la comunicación TLS con el servidor. Este certificado podemos provisionarlo desde el FTP a través del fichero de configuración, o bien configurar las opciones del DHCP para Lync Phone Edition. A mí personalmente me gusta hacerlo a través de estas opciones, porque de esta manera el cliente tiene todo listo si el día de mañana quiere conectar un modelo Polycom CX en su red.

En el siguiente articulo explicare como hacerlo

Parte 2: Configuración DHCP para Lync Phone Edition.

Cambiar el parametro “FailOverTimeout” para las llamadas PSTN en Lync

Posted on Actualizado enn

Recientemente nos encontramos con un problema a la hora de “tracear”. En concreto algunas llamadas que no se cursaban correctamente entre los clientes Lync/Skype contra algunos números externos, en esta ocasión era  numeración de Emergencia (062, 112, 091, etc …)

Concretamente cuando realizábamos la batería de llamadas y poníamos una traza de Wireshark en nuestros Mediation Server, veíamos lo siguiente:

Captura1

A los 10 segundos nuestro Mediation Sever enviaba siempre un “CANCEL” y la llamada no llegaba a cursarse:

Captura2

Indagando por la red dimos con la solución. Lync por defecto espera 10 segundos a que la llamada progrese y si no lo hace manda una opción “CANCEL” y la corta, no pudiendo ver de esta manera por qué la llamada no se cursa, o quizás este tipo de llamadas a números  de Emergencia estaban tardando más de lo normal en cursarse y con esta “restricción” no conseguían progresar.

Aunque parezca que Lync es un sistema bastante “restringido” a la hora de configurar sobre todo las opciones SIP que enviamos a nuestros TRUNKS, existen algunos ficheros de configuración en los cuales podemos cambiar (con mucho cuidado) parámetros como es el caso de “FailOverTimeour”. Esta opción por defecto está a 1000

      <add key=”FailOverTimeout” value=”10000″/>
<add key=”MinGwWaitingTime” value=”1″/>
<add key=”MaxGwWaitingTime” value=”20″/>
<add key=”FailuresForGatewayDown” value=”10″/>
<add key=”FailuresForGatewayLessPreferred” value=”25″/>
<!– Valid values are between 5 and 600 –>
<add key=”HealthMonitoringInterval” value=”300″/>
<!– Valid values are between 60 and 3600 –>
<add key=”GatewayStateReportingInterval” value=”1800″ />

Cambiándola a 2000 conseguimos subir a 20 segundos el tiempo que tarda nuestro Lync en enviar el “CANCEL”.

El fichero se llama “OutboundRouting.exe.config” y lo podemos encontrar en la ruta del servidor “C:\Program Files\Microsoft\Lync Server 2013\Server\Core“.

Captura3JPG

El fichero lo podemos Editar con “XML Notepad”, por ejemplo:

Captura4

La manera mas correcta de proceder a la hora de modificar ficheros de configuración de este tipo en Lync, o al menos la que aconsejo, es siempre hacerlo parando servicios de forma ordenada, servidor a servidor, lo que llamamos comúnmente “drenar los servidores”, y mas en arquitecturas con mas de un servidor en los Pool.

 

SIP/2.0 488 Invalid incoming Gateway SDP: Gateway ParseSdpOffer Error: No DTMF support on Gateway side.

Posted on Actualizado enn

En el siguiente artículo quiero abordar un problema que nos encontramos no hace mucho. Concretamente lo detectamos en algunas llamadas entrantes que no llegaban a los usuarios Lync de destino.

Concretamente se detectó que tras la implementación de la solución de Comunicaciones Unificadas de Microsoft, las llamadas entrantes desde una empresa concreta no llegaban y según les habían avisado la llamada se cortaba sin más.

Lo primero que hicimos fue sacar unas trazas con el Wireshark en los propios Mediation Server y haciendo pruebas de llamadas desde el origen concreto que fallaba, el resultado fue el siguiente:

91DDDDDDD;ext=8100Numero Destino

91OOOOOOONumero Origen

Sep 11 13:42:20.336 On XX.XX.XX.XX:32507 sent to XX.XX.XX.XX:5068
INVITE sip:+3491DDDDDDD;ext=8100@mediationserver.mrlync.com:5068;transport=tcp SIP/2.0
Via: SIP/2.0/TCP XX.XX.XX.XX:5066;branch=z9hG4bKnm3l563060ngul4dl4m1.1
From: <sip:+3491OOOOOOO@mrlync.com:32507>;tag=a16b6ae8-a0110ac-13c4-55013-768715-4170812a-768715
To: <sip:+3491DDDDDDD;ext=8100@mrlync.com:5068>
Call-ID: a11013e8-a0110ac-13c4-55013-768715-1bba52cc-768715
CSeq: 1 INVITE
Contact: <sip:91OOOOOOO@XX.XX.XX.XX:5066;user=phone;transport=tcp>
Max-forwards: 68
User-agent: Nortel CS1000 SIP GW release_7.0 version_ssLinux-7.50.17
P-asserted-identity: <sip:91OOOOOOO@mrlync.com;user=phone>
Privacy: none
History-info: <sip:8101@mrlync.com;user=phone?reason=sip%3bcause%3d302%3btext%3d%22Moved%20Temporarily%22>;index=1
History-info: <sip:89998100@mrlync.com;user=phone>;index=2
Allow: INVITE, ACK, BYE, REGISTER, REFER, NOTIFY, CANCEL, PRACK, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
Alert-Info: <cid:external@mrlync.com>
Content-Length: 143
Supported: x-nortel-sipvc, replaces
 
v=0
o=- 127866 1 IN IP4 XX.XX.XX.XX
s=-
c=IN IP4 XX.XX.XX.XX
t=0 0
m=audio 53890 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000

————————————-

FROM: <sip:+3491OOOOOOO@mrlync.com:32507>;tag=a16b6ae8-a0110ac-13c4-55013-768715-4170812a-768715
TO: <sip:+3491DDDDDDD;ext=8100@mrlync.com:5068>
CSEQ: 1 INVITE
CALL-ID: a11013e8-a0110ac-13c4-55013-768715-1bba52cc-768715
VIA: SIP/2.0/TCP XX.XX.XX.XX:5066;branch=z9hG4bKnm3l563060ngul4dl4m1.1
CONTENT-LENGTH: 0
 
 
—————————————-
Sep 11 13:42:20.388 On XX.XX.XX.XX:32507 received from XX.XX.XX.XX:5068
SIP/2.0 488 Invalid incoming Gateway SDP: Gateway ParseSdpOffer Error: No DTMF support on Gateway side.
FROM: <sip:+3491OOOOOOO@mrlync.com:32507>;tag=a16b6ae8-a0110ac-13c4-55013-768715-4170812a-768715
TO: <sip:+3491DDDDDDD;ext=8100@mrlync.com:5068>;epid=42EFB206DA;tag=2adf8e80cc
CSEQ: 1 INVITE
CALL-ID: a11013e8-a0110ac-13c4-55013-768715-1bba52cc-768715
VIA: SIP/2.0/TCP XX.XX.XX.XX:5066;branch=z9hG4bKnm3l563060ngul4dl4m1.1
CONTENT-LENGTH: 0
SERVER: RTCC/5.0.0.0 MediationServer

Poniendo una traza en el SBC para ver la parte del operador con el que el cliente tiene contratado el SIP TRUNK, vimos que algunas llamadas que fallaban llegaban con la siguiente información.

m=audio 47674 RTP/AVP 18 8

a=ptime:20

a=fmtp:18 annexb=no

Para que Lync acepte llamadas, el destino de la misma debe aceptar el envío de DTMFs y claramente en las trazas faltaba la información:

m=audio 55608 RTP/AVP 8 0 18 101

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

a=fmtp:18 annexb=no

m=image 58894 udptl t38

a=T38FaxVersion:0

a=T38FaxMaxBuffer:1100

a=T38FaxMaxDatagram:612

a=T38MaxBitRate:14400

a=T38FaxRateManagement:transferredTCF

a=T38FaxUdpEC:t38UDPRedundancy

Lo normal en esta ocasión era hablarlo directamente con el operador, pero al poder gestionar nosotros mismos en SBC del cliente,  por parte de nuestro ingeniero especializado en SBC de ORACLE se determinó que la mejor opción era modificar el “Codec-Policy” del propio SBC, sustituyendo este:

codec-policy

        name                           ToLync

        allow-codecs                   G729:no T.38:no PCMA PCMU telephone-event

        add-codecs-on-egress           PCMA PCMU

        order-codecs

        force-ptime                    disabled

        packetization-time             20

        dtmf-in-audio                  disabled

        last-modified-by               admin@

        last-modified-date             2013-09-16 10:14:40

Por el siguiente:

codec-policy

        name                           ToLync

        allow-codecs                   G729:no T.38:no PCMA PCMU telephone-event

        add-codecs-on-egress           PCMA PCMU telephone-event

        order-codecs

        force-ptime                    disabled

        packetization-time             20

        dtmf-in-audio                  disabled

        last-modified-by               admin@10.10.105.55

        last-modified-date             2013-09-16 10:14:40

De esta manera conseguimos que el SBC entregara la llamada correctamente a Lync y este las aceptara y entregara al destino.

Os recomiendo el siguiente artículo de Jeff Schertz, donde se explica el “Media Codecs” de Lync

http://blog.schertz.name/2014/03/media-codecs-in-lync-2013/

Cualquier problema al respecto que tengáis o que os podáis encontrar no dudéis en escribirme e intentare orientaros en lo posible, sé que muchos administradores de Lync/Skype no somos grandes expertos en protocolos pero a base de sacar y ver trazas al final podemos saber interpretarlas, pero desde luego la ayuda de un ingeniero especializado en este asunto nos puede salvar de más de algún problema.

Problema con la distribucion de usuarios en los “Routing Groups” de Lync 2013

Posted on Actualizado enn

Hoy quiero escribir este artículo acerca de un problema que me encontré hace un año aproximadamente en una migración de un entorno de Lync 2010 a Lync 2013, en concreto el problema se produjo al mover los usuarios desde un entorno al otro.

Tras montar toda la infraestructura de Lync 2013, movimos algunos usuarios de prueba al nuevo pool, después de unos días sin experimentar ningún problema y ver que todo estaba correcto, se decidió mover el resto de usuarios de la infraestructura, unos 5.000 usuarios.

Ese mismo día dejamos programado el Script que migraría todos los usuarios, el Script lanzaba el siguiente comando.

Get-CsUser -Filter {RegistrarPool -eq “lyncpool2010.mrlync.com”} | Move-CsUser -Target “lyncpool2013.mrlync.com”

¿Cuál fue nuestra sorpresa? Al día siguiente mientras los usuarios arrancaban los clientes Lync de sus ordenadores empezamos a notar lentitud en el comportamiento de los mismos, muchos de ellos se quedaban con las funciones limitadas, o no veían presencia, etc… Tras ver los problemas que estaban ocurriendo se decidió volver a mover los usuarios a la versión 2010 y todo volvió a la normalidad.

Parecía claro que a  los servidores no le sentaba bien la carga de usuarios, con lo cual procedimos a ir migrando usuarios en grupos de 50 en 50, en el momento que pasamos los 1500 usuarios volvimos a notar los problemas de rendimiento.

Nuestro primer pensamiento fue pensar que era un problema de rendimiento debido arquitectura, esta era la arquitectura que teníamos:

Diseño CPD

Teníamos un pool de FrontEnds con redundancia geográfica dividido en dos Sites separados físicamente en dos CPD, sabíamos que con 4 FrontEnds teníamos más que suficiente para aguantar la carga de los 5000 usuarios, por ello nos centramos en que el problema pudiera ser la conexión de red entre los dos CPD, pero los tiempos y la calidad de red parecía correcta, por otro lado pensamos en que el fallo podría estar en la conexión de los FrontEnd con el BackEnd y que por alguna razón teníamos un cuello de botella, pero al igual que el caso anterior todo parecía correcto.

Tras las pruebas y descartar que el problema pudiera ser causa del rendimiento de los servidores comenzamos a revisar la configuración y el comportamiento de los servidores de  Lync 2013 y sus Routing Groups.

Tras el movimiento de usuarios vimos que todos se metían en el mismo Routing Group cuando la manera correcta seria que se distribuyeran entre varios. Para comprobar los Routing Groups, hicimos consultas a la BBDD RTC Local de los FrontEnd, o el atributo msRTCSIP-UserRoutingGroupID.

Routings

Pero casualmente en una de las pruebas que lanzamos fue usando la consola de Administración de Lync y la sorpresa fue ver que los usuarios si se distribuían bien. Tras este comportamiento decidimos probar con la consola de Powershell Remoto contra uno de los servidores y lanzamos el movimiento de usuarios en grupos de 50 en 50, ¿Cuál fue el resultado? Todos los usuarios se movieron de forma correcta y se acabaron los problemas de rendimientos.

En conclusión, el problema era que los primeros script de movimiento de usuarios los hacíamos con el “Lync Server Management Shell” en el propio servidor de Lync.

Captura lync shell

Y tras utilizar un script que abría una consola de PowerShell remoto en Lync todos los usuarios se distribuían correctamente. ¿Por qué cuando lanzábamos el mismo comando PowerShell desde la consola de PowerShell del servidor no se distribuían bien los usuarios? No he conseguido encontrar la explicación coherente, pero estaba claro que ejecutar el movimiento de usuarios desde el propio PowerShell de Lync nos daba problemas

Desde este problema todas las instalaciones o migraciones de Lync que realizo, el PowerShell remoto se ha convertido en un elemento obligatorio para la administración, aunque sea en un único Servidor Standard Edition.

Para entender más acerca de cómo funcionan los routing groups, os recomiendo la siguiente página:

http://masteringlync.com/2013/10/29/understanding-how-windows-fabric-works/

Con respecto al script de conexión de powershell remoto, encontrareis muchas maneras de hacerlo en internet, cualquiera de ellas os servirá, la que yo utilizo es la siguiente:

En un fichero TXT copiamos el siguiente código

$Cred = Get-Credential “mrlync\lyncadmin”
$Session = New-PSSession -ConnectionURI “https://lyncserver01.mrlync.com/OcsPowershell”-Credential $cred
Import-PSSession $sesión

Este fichero lo renombramos a *.ps1 y lo ejecutamos desde el PowerShell, con este formato nos pedirá clave de “lyncadmin” cada vez que lo ejecutemos. En algunos entornos puede haber mucho movimiento en lo que a las bajas y altas de la compañía respecta, de esta manera podemos dejar un script de PowerShell remoto para que gestione las altas en Lync teniendo la contraseña de administrador en otro fichero encriptado para que se ejecute de forma automática, esta gestión de las altas de usuario en Lync las abordaré en otro artículo en el que explicare como crear un proceso automático de altas en el que incluso se asignen las políticas según el perfil de usuario.

Problemas de incompatibilidad de versiones de 802.1x – Teléfonos Polycom y Avaya – Parte 2

Posted on Actualizado enn

En este segundo artículo, paso a contar como solucionamos el problema de securiación con la incompatibilidad de 802.1x. En principio ADAC como comentamos en el primer artículo es un sistema propietario de AVAYA para su telefonía VoIP y su electrónica de red, pero finalmente y gracias al fabricante pudimos ponerlo para los teléfonos Polycom dedicándole una VLAN dedicada para el registro de los teléfonos.

A continuación añado las capturas de configuración de los Switch de planta

1.- A nivel Global la configuración de 802.1X

switch01

2.- A nivel de puerto en el Switch se aplica la siguiente configuración

switch02

3.- Y por último se añadió el rango de las MAC de los teléfonos Polycom

switch03.2

Quiero advertir ante todo que estas capturas son muy genéricas, en cada cliente las configuraciones de este tipo pueden ser muy particulares, pero la intención de este artículo es orientar en el caso de que alguien se encuentre en una situación parecida, que sepa que puede usar ADAC en electrónica AVAYA con los teléfonos Polycom.

Hay otra manera que es usando autenticación por MAC, esto requiere ir añadiendo las MAC, una a uno de los teléfonos, evidentemente en una instalación con un número elevado de teléfonos esto puede ser engorroso. Pero existe la manera de hacerlo con reglas como se muestra en la siguiente captura

switch04

No soy un experto en la configuración de electrónica de red, por ello en un caso parecido a este siempre aconsejo primero hablar con el Integrador o el fabricante para que nos ayude en la manera de lo posible.

Nos leemos en el próximo articulo

Problemas de incompatibilidad de versiones de 802.1x – Teléfonos Polycom y Avaya – Parte 1

Posted on Actualizado enn

En mi primer artículo que publico quiero abordar un problema que nos encontramos con los teléfonos Polycom VVX 410 y la securizacion de red del cliente. Este artículo se compone de dos partes, en la primera parte desarrollare el problema y como conseguimos detectarlo.

En los proyectos en los que he trabajado para migrar el sistema de voz y comunicaciones a un sistema de Microsoft Lync Server me he encontrado en situaciones en las que el cliente ha planteado un despliegue más agresivo y ha ido retirando los teléfonos y sustituyéndolos por dispositivos usb y poniendo solo teléfonos de área común en salas de reuniones y zonas comunes. Sin embargo, otros clientes han planteado un despliegue menos agresivo para el usuario, y han decido sustituir los teléfonos tradicionales por teléfonos Lync sobre todo para los perfiles de directivos, secretarias, etc ….

De los modelos con los que he trabajado a parte de algún modelo de SNOM, he trabajado sobre todo con Polycom, CX3000, CX600, CX500, y los VVX410 y VVX600, en mi opinión los más fáciles de desplegar son los modelos CX, pero la impresión del usuario es que el VVX410 se manejan mejor y además muchas de sus opciones pueden ser configuradas por los administradores, en mi opinión so más potentes pero no son fáciles de desplegar, en otro artículo abordare como preparé el despliegue de unos 600 teléfonos VVX en un cliente, sobre todo las opciones del fichero de configuración que elegimos para el despliegue.

En el cliente tenían una desplegada Voz IP con una Centralitas AVAYA CS1K y aparte toda la electrónica de red es del mismo fabricante, la electrónica Avaya tiene una opción que se llama ADAC, la cual permite al Switch controlar los teléfonos IP para registrarlos en la red mediante LLDP de esta manera el Switch negocia con el teléfono y le deja registrarse en la red, evidentemente ADAC está pensado para funcionar con teléfonos propietarios del fabricante. Aquí os dejo un pequeño esquema donde se puede entender el funcionamiento de ADAC.

img1

http://www.voxns.com/understanding-ip-phone-deployment-lldp-med-provisioning/

Si necesitáis más información acerca de esto y todo lo relacionado con el mundo AVAYA, os recomiendo que leáis el blog de Michael Mcnamara http://blog.michaelfmcnamara.com

Pues bien, el cliente en concreto quería mantener con los nuevos teléfonos la autenticación en la red. Para ello se planteó inicialmente 802.1x que es soportado tanto por la electrónica de red AVAYA como por los teléfonos VVX, de esta manera podíamos autenticar contra un servidor radius los teléfonos Polycom.

Implementar 802.1x en los teléfonos nos dio muchos quebraderos de cabeza, no fue nada fácil cargar los certificados del dispositivo generándolos con la entidad certificadora del cliente. En el siguiente enlace esta toda la información oficial de Polycom para implementar 802.1x en los teléfonos.

http://support.polycom.com/global/documents/support/technical/products/voice/802_1X_TB57352.pdf

La opción que decidimos implementar fue EAP-TLS, una vez configurado el teléfono con los certificados correspondientes no fuimos capaces de ver ningún registro del teléfono en el Radius. Después de varios intentos, pusimos una traza y este fue el resultado:

  • Según la traza que capturamos el switch avaya soporta 802.1X – 2001

img2

  • Y el teléfono Polycom soporta 802.1x – 2004

img3

Este era el motivo por el cual no conseguíamos que el teléfono llegara al servidor Radius ya que la propia electrónica de red no era capaz de entenderse con el. La solución fácil pasaba por una actualización de la electrónica de red pero tras conversaciones con el fabricante no había actualización para el modelo de switch que tiene el cliente en sus instalaciones. Por ello tuvimos que encontrar otra solución, que pasaba por usar ADAC y mediante el rango de las MAC de los teléfonos registrarlos en una VLAN dedicada. En la segunda parte del articulo pasare a contar la solución que se desplego.