Microsoft Lync Server
Header
Como sabéis ahora para poder compartir nuestras presentaciones de PowerPoint  en una conferencia de Lync, necesitamos tener WAC configurado (Office Web APPs con SharePoint y Lync Server 2013). Si queremos acceder desde internet a las conferencias o tenemos gente fuera de la organización conectada, claramente debemos publicar el acceso al WAC. Sino lo hemos publicado correctamente, podemos encontrarnos con el siguiente error
 TMG_Publicacion_122.png
La publicación mediante reverse-proxy lo hemos hecho con TMG, por lo que debemos revisar los logs de conexión para encontrar el problema. Para ello nos vamos a la opción de Logs &Reports y lanzamos de nuevo la conferencia y compartimos nuestra presentación para tratar de reproducir el problema. Configuramos un pequeño filtro en la monitorización para que solo nos muestre las conexiones que coincidan con la regla de publicación del WAC, para ello pulsamos  en Edit Filter
TMG_Publicacion_123.png
Añadirmos el siguiente filtro:
Filter by: Rule
Condition: Contains
Value: Nombre_Regla_Publicación_WAC
una vez que hemos elegido las distintas opciones pulsamos en Add To List
TMG_Publicacion_124.png
Pulsamos en Start Query
TMG_Publicacion_125.png
a reproducir el error, debemos iniciar de nuevo una conferencia y compartir una presentación de PowerPoint
TMG_Publicacion_79.png
: Blocked by the HTTP Security Filter: URL normalization was not. Esto tiene muy fácil solución, debemos ir a la regla de publicación de WAC, pulsar con el botón derecho encima de la misma y hacemos clic en Configure HTTP
TMG_Publicacion_127.png
En la pestaña General  desmarcamos la casilla de Verify normalization y pulsamos Aplicar
TMG_Publicacion_128.png
ahora volvemos iniciar una conferencia y compartir la presentación, si volvemos al TMG  observamos que no tenemos error alguno
TMG_Publicacion_80.png
de tal forma que todos los participantes de la conferencia podrán ver correctamente la presentación
TMG_Publicacion_129.png
Si queréis ampliar más información sobre los filtros HTTP aquí os dejo el siguiente enlace: Configuring HTTP filtering
Espero que os sea de utilidad!!!

​El Protocolo de inicio de sesión (SIP) se usa para iniciar y administrar sesiones de comunicaciones de voz sobre IP (VoIP) del servicio telefónico básico y otros servicios de comunicación en tiempo real: IM, Conferencias, Presencia, etc… Seguramente en alguna ocasión habéis escuchado el término Direct SIP o Trunk SIP, algo muy común cuando queremos conectar nuestro Lync con un ITSP y otra IP-PBX poder utilizar servicio de Telefonía IP Empresarial

Direct_SIP_Trunk_SIP.jpg

Veamos una definición muy simple de que es un Trunk SIP o Direct SIP (teniendo en cuenta que siempre estará un servidor de Lync presente, pero no tiene porque ser así)

Trunk SIP: Conexiones SIP entre dos dispositivos independientes,  por ejemplo nuestro servidor Lync y un ITSP o enlaces SIP entre dos sedes conectadas mediante VPN, MPLS, etc..

Direct SIP: Son conexiones SIP entre dos dispositivos que se conectan de forma directa en la misma red local, por ejemplo nuestro servidor Lync y un enlace de red telefónica conmutada (RTC) o un sistema IP-PBX. Pero siempre de forma local, en ningún momento se conecta fuera de la red local.

Los Trunk SIP se suelen utilizar para conectar nuestras implementaciones de Lync con un proveedor de telefónia por internet (ITSP), lo que permite un abaratamiento del coste de las llamadas, mantenimiento, etc.. puesto que utilizaremos nuestra conexión de datos para conectarnos con el ITSP. Esto elimina la necesidad de contratación de líneas a un proveedor de telefonía tradicional (Vodafone, Telefónica, Orange, etc…) con líneas Básicas, BRI, PRI, etc….  También es muy común que este tipo de conexiones se establezcan mediante una VPN, lo que permite securizar las comunicaciones entre ambas redes. A la hora de dimensionar los enlaces WAN, debemos tener en cuenta el número de llamadas simultáneas que tendremos en el momento de máxima carga. Esto evitará las líneas WAN saturadas, esto causará problemas en las llamadas. Como referencia podéis tomar la sigiuiente métrica:

Ancho de banda máximo del Trunk SIP = Nº máx. de llamadas simultáneas x (64 kbps + tamaño de encabezado).

Lync Server 2013 solo admite los siguientes códecs:

  • G.711A (que se usa principalmente fuera de Norteamérica)
  • G.711µ (que se usa en Norteamérica)

Esto es algo que debéis tener muy presente, puesto que condicionará (o podría hacerlo) la implementación e iteracción con el ITSP. Todos los ITSP soportan ambos códecs, pero en caso contrario debemos tener un Gateway que pueda hacer transcoding.

Los Direct SIP se muy común su utilización cuando queremos conectar nuestro Lync con una centralita IP-PBX para conectar a los usuarios de Lync con los usuarios de la telefonía tradicional o ls PSTN. Estas conexiones son de ámbito interno, por lo que no necesitan atravesar la WAN para establecer comunicación con el otro extremo. Aqui el ancho de banda no es un factor clave a la hora de planificar el dimensionamiento de los enlaces, puesto que se supone que son enlaces a 100 o 1000MBits. Pero de todas formas debemos tener en cuenta la misma métrica que con los Trunk SIP:

Ancho de banda máximo del Trunk SIP = Nº máx. de llamadas simultáneas x (64 kbps + tamaño de encabezado)

Ahora quedaría como podemos configurar un Trunk SIP o Direct SIP en Lync, pues os adelante que la configuración es la misma en ambos escenarios. Para Lync no existe diferencia alguna a la hora de su configuración. En una conexión de Direct SIP se conectará  utilizando como destino una IP Privada y en el Trunk SIP se utilizará una IP Pública como destino. Puesto que el Lync en el Direct SIP se conectará a un elemento de dentro de su red local, y en el Trunk SIP nos conectaremos a nuestro ITSP.

Para configurar ambos modelos de conexión, debemos disponer de un Mediation Server en nuestra organización. Los Mediation server suelen tener dos tarjetas de red, una para la conexión con la red local y otra para la conexión con las puertas de enlace. Lo primero que debemos configurar es nuestra puerta de enlace IP/RTC, para ello abrimos el Generador de Topologías y pulsamos en Nueva puerta de enlace IP/RTCDirect_SIP_Trunk_SIP_1.png

Direct_SIP_Trunk_SIP_2.png

escribimos el FQDN o IP de la puerta de enlace RTC (si la conexión será con TLS debemos escribir el FQDN en vez de la IP)

Direct_SIP_Trunk_SIP_3.png

seleccionaremos el modelo de comunicación con la puerta de enlace

ahora debemos cubrir el puerto que utiliará el Mediation Server para recibir las respuestas de la puerta de enlace, y el puerto que utilizaremos para conectarnos con el asociado (puerta de enlace RTC). Además, debemos seleccionar el Mediation Server al cual le vamos a asociar esta puerta de enlace y también el protocolo de transporte SIP (TLS o TCP). Los puertos estándar para los protocolos de transporte son los siguientes:

  • TCP: 5060
  • TLS: 5061

Direct_SIP_Trunk_SIP_4.png

Esto no impide que utilicéis otro diferente siempre y cuando no esté en uso

Ahora ya tenemos nuestra puerta de enlace IP/RTC configurada con su Trunk asociadoDirect_SIP_Trunk_SIP_5.png

Si queremos tener más de un trunk asociado debemos agregar nuestro troncos desde el generador de topologías, de tal forma que podemos tener más de un tronco configurado a nuestra puerta de enlace IP/RTCDirect_SIP_Trunk_SIP_6.png

Ahora debemos publicar la topología  y configurar la parte de Voz desde las opciones de Enrutamiento de Voz desde el Panel de Control de Lync. Debemos configurar
Direct_SIP_Trunk_SIP_7.png
Para que podáis ver esta configuración os dejo aquí dos artículos que había escrito hace unos meses:

Por último vamos a ver otro concepto, el Inter-Trunk Routing que permite a Lync Server el enrutamiento entre trunks:

  1. Lync Server 2013 ofreciendo interconexión a una puerta de enlace RTC y un sistema IP-PBX (imagen de MSFT)
Direct_SIP_Trunk_SIP_8.png
2. Lync Server 2013 conectando dos sistemas IP-PBX (imagen de MSFT)

Direct_SIP_Trunk_SIP_9.png

La configuración de estos escenarios es similar a los anteriores, puesto que tenemos que especificar porque que enlace enviar las llamadas en función de las numeraciones de destino, etc…

Si queréis entrar en más detalles aquí os dejo un enlace de MSFT: http://technet.microsoft.com/es-es/library/gg425749.aspx

Espero que os haya sido de utilidad!!!

​ ​Este error suele ser bastante común cuando los clientes de Lync se conectan desde sistemas operativos anteriores a Windows 7, los usuarios no pueden iniciar sesión aunque estén escribiendo correctamente sus credenciales de inicio de sesión

eventid_lync_14614_2.jpg

 

Si vamos al Front-END nos encontraremos el siguiente evento con el ID 14614eventid_lync_14614_1.jpg
Nombre de registro:Lync Server
Origen:        LS Protocol Stack
Fecha:         29/01/2013 14:58:38
Id. del evento:14614
Categoría de la tarea:(1001)
Nivel:         Error
Palabras clave:Clásico
Usuario:       No disponible
Equipo:        XXXXX.XXXXXX.XXX
Descripción:
Error de autenticación de usuario con el protocolo NTLM: SEC_E_UNSUPPORTED_FUNCTION. Esto indica una posible falta de coincidencia entre la configuración de directiva de seguridad en los equipos cliente y servidor.

 
Esto es debido a la configuración de NTLM del Front-END y la configuración por defecto en sistemas anteriores a Windows 7. En la directiva Seguridad de red: seguridad de sesión mínima para servidores NTLM basados en SSP (incluida RPC segura) nos encontramos con el siguiente valor por defecto: Requerir cifrado de 128 Bits

eventid_lync_14614_3.jpg

INFORMACIÓN DE LA DIRECTIVA

Esta configuración de seguridad permite a un servidor requerir la negociación del cifrado de 128 bits y/o la seguridad de sesión NTLMv2. Estos valores dependen del valor de la configuración de seguridad Nivel de autenticación de LAN Manager. Las opciones son:
  • Requerir seguridad de sesión NTLMv2: se producirá un error en la conexión si no se negocia el protocolo NTLMv2.
  • Requerir cifrado de 128 bits: se producirá un error en la conexión si no se negocia el cifrado de alta seguridad (128 bits).
Valor predeterminado:
  • Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003 y Windows Server 2008: sin requisitos.
  • Windows 7 y Windows Server 2008 R2: requerir cifrado de 128 bits
Lo que tenemos que hacer es desmarcar la opción de Requerir cifrado de 128Bits y los clientes se podrán conectar sin problema
eventid_lync_14614_4.jpg
Espero que os sea de utilidad!!!

Seguro que esta herramienta hará las delicias de más de uno, puesto que es una excelente herramienta de análisis de las conexiones del cliente Lync  de Windows Store y el cliente móvil

Enlace de descarga: Microsoft Lync Connectivity Analyzer (64 Bit)

Una vez que lo hayáis descargado e instalado lo ejecutamos y nos encontramos la siguiente consola en donde debemos cubrir algunos datos para empezar con el test de conexión

SIP URI: dirección SIP

Password: Contraseña

Username: usuario en el caso de que el SIP sea diferente al usuario de inicio de sesión

Lync Server Discover: método de descubrimiento del servidor: Automático o Manual

Network Access: Podemos elegir si queremos probar el acceso desde internet o desde la red local

Test the requeriments for: podemos elegir si el test se para el cliente Lync Mobile o el cliente Lync del Store (Windows 8)

LyncConnectivityAnalyzer_2.jpg

Tenemos opciones adicionales como en donde se almacenará el log de los resultados del text y si queremos enviarmos el resultado del informe por correo electrónicoLyncConnectivityAnalyzer_3.jpg

LyncConnectivityAnalyzer_11.jpgLyncConnectivityAnalyzer_12.jpg

Una vez que hemos introducido los datos pulsamos en Start y empezaré el test de conectividad, tenemos varios niveles de detalle

SummaryLyncConnectivityAnalyzer_4.jpg

All resultsLyncConnectivityAnalyzer_6.jpg
Detail informationLyncConnectivityAnalyzer_6.jpg

Además tiene un cajón de búsqueda que nos permite filtrar el informe por la palabra que buscamos, esto nos facilitará al análisis del informeLyncConnectivityAnalyzer_10.jpg

Si queremos enviarmos el fichero de log por e-mail vamos a la pestaña de Options, escribimos nuestra dirección de correo y pulsamos en Send log fileLyncConnectivityAnalyzer_8.jpg

Ahora se nos abre nuestro gestor de correo electrónico (Outlook en mi caso) y ahora debemos adjuntar el fichero de log como nos describe en cuerpo del e-mailLyncConnectivityAnalyzer_7.jpg

Aqui os muestro parte del detalle de un fichero de logLyncConnectivityAnalyzer_9.jpg

Seguro que os será de utilidad, os facilitará información muy útil

Espero que os sea de utilidad

​Seguramente en cualquier implementación de telefonía en la que hayáis particiado, habéis tenido alguna solicitud por parte del cliente de que algún usuario o grupo de usuarios no puedan realizar llamadas la PSTN

Bloqueo_LLamadas_PSTN_Esquema.jpg

Pensemos en la típica situación en la cual  tenemos todo configurado para poder llamar a la PSTN, con sus reglas de marcado, normalización, usos de RTC, etc… .  Tenemos varios usuarios a los cuales  solo queremos permitir que reciban llamadas, que puedan hacer llamadas únicamente a los usuarios de Lync  y a otros usuarios de teléfonos conectados a una PBX. Este escenario es muy común sobre todo en empresas que están empezando con la migración de su sistema de telefonía a Lync, el tener usuarios con Lync y otros con los teléfonos conectados a la PBX (Migrar un entorno IP-PBX a Lync 2013).

Una vez conociendo el escenario y lo que ya tenemos implementado, vamos a ver una forma fácil de evitar que los usuarios puedan llamar a números de la PSTN. Lo que haremos será crear una nueva Directiva de Voz y configurar un Uso de RTC personalizado evitando que puedan llamar a números que no sean las extensiones de los teléfonos de la PBX. Para ello abrimos el Panel de Control de Lync – Enrutamiento de Voz – Directivas de Voz – Agregar – Directiva de Usuario

Bloqueo_LLamadas_PSTN_1.jpg
Ahora cubrimos los datos que nos muestra y habilitamos o deshabilitamos las opciones que queramos según nuestra instalación

Bloqueo_LLamadas_PSTN_2.jpg
Ahora lo que debemos hacer asociar un RTC en el cual especifiquemos que números vamos a permitir marcar y por que tronco (esta traducción 🙁 ) se cursarán las llamadas para este RTC, para ellos pulsamos en Agregar para crear un Uso de RTC nuevo o seleccionar uno ya existente, en nuestro caso vamos a crear uno nuevo
Bloqueo_LLamadas_PSTN_3.jpg
Ahora escribiremos nombre y descripción para nueva ruta de voz, además  únicamente voy a permitir llamadas que el primer dígito comience por 2 (rango de extensiones internas) y seleccionamos el tronco por el que vamos a enviar las llamadas a estas extensiones. En nuestro caso hemos configurado previamente el Direct SIP entre el Lync y un Cisco CME para poder comunicar ambos ambientes

Bloqueo_LLamadas_PSTN_4.jpg
Si realizamos un test veremos que solo podemos hacer llamadas a los números que comiencen por 2 el resto no será posible

Extensión o número 201

Bloqueo_LLamadas_PSTN_5.jpg

Extensión o número 301

 

Bloqueo_LLamadas_PSTN_6.jpg
Ahora guardamos esta ruta de voz y vemos que se ha añadido directamente al Uso de RTC que estamos creando, solo tenemos como disponible todas las llamadas cuyo patrón comience por el número 2, pulsamos en Aceptar para guardar
Bloqueo_LLamadas_PSTN_7.jpg

ahora volvemos a la ventana de configuración de la Directiva de Voz y vemos que se ha añadido el Uso de  RTC que hemos creado

Bloqueo_LLamadas_PSTN_8.jpg
En cuanto a la configuración del desvío de llamadas simultáneas y desvío o voy a dejar con la opción por defecto, de tal forma que los usuarios puedan configurar los desvíos de llamadas o simultaneidad de las mismas pero siempre a números internos (números cuyo patrón coincida con lo establecido en la RTC). Una vez que tenemos nuestra directiva creada debemos confirmar los cambios para que se guarden, para ello pulsamos en Confirmar – Confirmar todo
Bloqueo_LLamadas_PSTN_9.jpg
Bloqueo_LLamadas_PSTN_10.jpg

Bloqueo_LLamadas_PSTN_11.jpg
Bloqueo_LLamadas_PSTN_12.jpg

Lo último que nos queda por hacer, es añadir esta directiva de Voz al usuario y/o usuarios a los que queremos restringir las llamadas, para ello podemos hacerlo mediante PowerShell o desde el Panel de Control de Lync, vamos a verlo de ambas formas:

PowerShell

Sintaxis

Grant-CsVoicePolicy -Identity nombre_usuario -PolicyName Nombre_Directiva

Ejemplo:

Grant-CsVoicePolicy -Identity sbuitrago@asirsl.com -PolicyName DV_NO_PSTN

Bloqueo_LLamadas_PSTN_13.jpg

Panel de Control: Buscamos el usuarios  y editamos sus preferencias

Bloqueo_LLamadas_PSTN_14.jpg
seleccionamos la Directiva de Voz que hemos creado anteriormente y pulsamos en Confirmar, ni que decir tiene que el usuario debe tener habilitada la Telefonía Empresarial

Bloqueo_LLamadas_PSTN_15.jpg
Una vez que hemos finalizado la configuración, debemos iniciar sesión con el usuario al cual le hemos aplicado la Directiva de Voz y probar que realmente funcione como esperamos. Si llamamos a una extensión interna la llamada ser cursará con normalidad

Bloqueo_LLamadas_PSTN_16.jpg

Y si tratamos de hacer una llamada a la PSTN (o cualquier número distinto que no coincida con el patrón que hemos configurado) la llamada no ser cursará

Bloqueo_LLamadas_PSTN_17.jpg
Como vemos no tenemos que modificar ni crear nuevas reglas de marcado, etc.. así nos evitamos el tener que crear todo de nuevo, de hecho las reglas de normalización han funcionado correctamente.  Nosotros tenemos configurado que todas las llamadas  a las PSTN se envíen a nuestro ISTP con el 0034 delante del número marcado y como podéis apreciar eso no ha cambiado:

Bloqueo_LLamadas_PSTN_18.jpg
Si ahora queréis que los usuarios puedan llamar a otros números únicamente debéis ir añadiendo los dígitos que queremos permitir en la ruta de voz

Espero que os sea de utilidad!!