Edge Server

Implementar “Call Admission Control – CAC” en Skype for Business. Parte 2

Posted on Actualizado enn

Implementar “Call Admission Control – CAC” en Skype for Business. Parte 1

Continuamos con la implementación de Call Admission Control – CAC en Skype for Business, algo que como ya conté en la Parte.1 del articulo, es raro encontrarse en la implementaciones de Skype/Lync, al menos en las que yo he trabajado, es algo que el si no pide expresamente el cliente, los propios administradores o implementadores no solemos poner.

En esta segunda parte, sobre un ejemplo de una infraestructura voy a explicar como diseñar CAC.

Diseño de Skype for Business

Imaginemos que tenemos el siguiente diseño en Skype for Business.

imagen 1.jpg

En este diseño tenemos una implementación de SKYPE FOR BUSINESS con un SITE Principal que esta en Madrid, con su Pool de Edge que actuará como ruta principal para la Federación de todo el entorno, además tenemos un SIP TRUNK que será por el que sacaremos las llamadas.

También tenemos dos sitios remotos, una oficina en Barcelona, con su salida a la PSTN y otro en UK, concretamente en la oficina estará en Londres. También con salida a la PSTN.

El Pool principal con sus Sitios Remotos estará conectado a través de una WAN.

Como ya vimos en el articulo anterior, CAC actuara sobre la WAN de estos Sitios Remotos.

Diseño de “Call Admission Control – CAC”

Una vez que ya tenemos nuestra infraestructura de Skype diseñada, podremos empezar a pensar en el diseño de CAC, normalmente el cliente nos podrá dar que anchos de banda y limites quiere, pero si no nos tocara a nosotros hacer el calculo. Para ello tendremos que tener en cuenta la tabla de Anchos de Banda y Consumos de Skype y sus códec.

UTILIZACION DE ANCHO DE BANDA SEGUN EL CODEC

CaptureTable1.JPG

UTILIZACION DE ANCHO DE BANDA SEGUN EL ESCENARIO

CaptureTable3.JPG

Para nuestro ejemplo en el que estamos trabajando vamos a usar para los sitios de Barcelona y Londres la misma configuración de CAC

Audio Limit 3072 Kb
Audio Session Limit 175 Kb
Video Limit 2048 Kb
Video Session Limit 384 Kb

Para implementar CAC debemos tener claro los siguientes términos:

Para diseñar nuestro CAC deberemos determinar cual será nuestra Regiones de Red (Network Región) por ejemplo, podemos tener una Región de Red para Europa y otra para America del Norte, después en cada Región de Red tendremos el Sitio Central (Central Site), por ejemplo, para la Región de Europa, el Central Site será Madrid y para Norte América será Chicago. Además tendremos nuestros Sitios de Red (Network Sites), que será donde apliquemos la limitación de CAC. En nuestro caso es, Barcelona y Londres.

Para el ejemplo en el que estamos trabajando, tenemos el siguiente diseño

imagen 2.jpg

Network Region Central Site Network Sites
EMEA Madrid Barcelona
  London

“Cannot start RTCSRV Service” – Specific error code – 2147014847. Skype for Business Access Edge on Local Computer (English)

Posted on Actualizado enn

This is my first article in English, now I will combine the articles in Spanish and English to facilitate the work of visitors. My English is not very advanced but I hope to help with my articles to all who encounter the same problems that I have found and here I am telling. Or simply the intention to use English is to reach more lovers of microsoft unified communications, Skype world for business, office 365, cloud, and etc…

I chose this last article, a problem which I have already met several times “Cannot start RTCSRV Service”. When the RTCSRV service is not started on the EDGE server, It can be normally for the following reasons:

– Problem with some of the certificates
– Some of the latest updates installed
– Some cumulative update of Skype for Business

This is what I usually find in some customers, but, this time, the situation was different, first, I will show the design.

diseno-1-blog-edge

Is noteworthy in this design that external firewall in DMZ is no NAT, the public IP addresses are directly posted on the Internet. This design was working fine until we installed the CU of June 2016 in the EDGE Server and we installed the security updates for Windows, when we restart we saw that the service “Skype for Business Server Access Edge” gave us the following error:

error-1-blog-edge

The first thing we did was uninstall updates, to restart the service, we saw these two errors:

error-2-blog-edge

error-3-blog-edge

After seeing that none of the usual reasons were the cause of the error, we remember that not long ago the customer changed the approach in its public IP address. Returning to the initial design. The “Public IP 1” and “Public IP 4” we had the same IP in the network interface for “sip.dominio.com” and the Rever Proxy:

diseno-2-blog-edge

There was a problem of incompatibility in the design and the Server was unable to start the Service.

“Cannot start RTCSRV Service” – Specific error code – 2147014847. Skype for Business Access Edge on Local Computer (Castellano)

Posted on Actualizado enn

“Cannot start RTCSRV Service” – Specific error code – 2147014847. Skype for Business Access Edge on Local Computer (Castellano)

Después de una larga temporada sin escribir, retomo el blog con este error que me encontré en un cliente y casualmente después de actualizar al ultimo CU de junio de 2016. Antes de pasar a detallar los detalles de como fue lo que me encontré y como lo solucionamos, me gustaría adelantaros mi intención de empezar a escribir alternativamente los post, en Ingles y Castellano, se que será difícil ya que es trabajo doble, pero una llamada que recibí hace poco y ver el origen de las visitas que recibe las entradas del blog me han llevado a tomar esta decisión, por eso he puesto (Castellano) en el titulo del post.

Bueno, pasemos a detallar el problema encontrado, como siempre hago, os lo contare de forma coloquial, y veréis que mas que un problema técnico lo que nos encontramos fue un problema de diseño que por casualidades “salto” o apareció después del reinicio típico después de actualizar el CU del EDGE.

Lo primero que hay que tener en cuenta es el diseño aproximado de este cliente en concreto para entender el “porque”.

diseno-1-blog-edge

Importante en este diseño que en firewall externo de la DMZ no había NAT, las IP’s publicas están directamente publicadas con la IP publica tanto para el EDGE server como para el Proxy Reverso que en este caso es un KEMP.

Pues bien, este diseño, estuvo funcionando bien hasta que casualmente le pasamos el CU de junio 2016 al EDGE server y parcheamos el servidor, una vez realizamos esto, reiniciamos y levantamos los servicios pero al levantar el servicio de “Skype for Business Server Access Edge” nos daba el siguiente error:

error 1 blog edge.jpg

Con ello, nos pusimos a buscar en y lo primero que pensamos era que podía ser la actualización, lo primero que hicimos fue quitar el CU instalado desde el panel de control, claro al levantar el servicio en este caso veíamos estos dos errores:

error 2 blog edge.jpg

error 3 blog edge.jpg

Seguíamos sin poder levantar el servicio de acceso, tras repasar e instalar de nuevo los certificados,  llegamos incluso a plantearnos recuperar un back up de la propia maquina virtual pero no tenia mucho sentido, entonces caímos en que habíamos no hace mucho tiempo cambiado un planteamiento en su direccionamiento IP publico. Y efectivamente ahí estaba el problema. Volviendo al diseño inicial. La “Public IP 1” y la “Public IP 4” eran la misma, teníamos por error la misma IP configurada en el interfaz de la tarjeta de red para “sip.dominio.com” y para el Proxy Reverso:

Diseño 2 blog edge.jpg

 Con lo cual había un problema de incompatibilidad y el Servidor era encapad de levantar el servicio. Una vez cambiamos la IP en el interfaz del KEMP pudimos levantar el servicio sin ningún problema.