Mediation Server

Parte III: Microsoft Teams DR en Azure – Configuración básica del SBC

Posted on

DESPLIEGUE DE AUDIOCODES SBC VE EN AZURE

En esta 3ª entrega vamos a ver la configuración básica del SBC, en este articulo vamos a explicar:

  •  Prerrequisitos de la implementación
  •  Configuración básica de Seguridad
  •  Configuración TLS

Prerrequisitos de la implementación

¿Qué necesitamos para la configuración?

  • Certificado Publico con al menos un SAN, no hace falta que sea multi SAN.
  • Dar de alta en el DNS publico el FQDN del SBC
  • Diseño de puertos y protocolos.
To SIPTrunk Proxy Set 5061
Señalización UDP – TCP 5060
Media 6000 – 6500
To TEAMS Proxy Set 5061
Señalización TLS – 5067
Media 7000 – 7500
  • Direccionamiento IP de Teams

52.114.148.0 | 52.114.132.46 | 52.114.75.24 | 52.114.76.76 | 52.114.7.24 | 52.114.14.70

sip.pstnhub.microsoft.com | sip2.pstnhub.microsoft.com | sip3.pstnhub.microsoft.com

Diseño de puertos y protocolos

En el diseño final quedaría de la siguiente manera.

Part 3_001

Por un lado, tenemos la parte de Direct Routing, que conecta el SBC con Teams, para ello nos registraremos con el Proxy Set 5061, la señalización es SIP/TLS por el puerto 5076 y el trafico de MEDIA es el rango 7000 – 7500. En el caso de la PSTN, Tenemos la IP del SipTrunk contra el que nos registramos por el puerto 5061, pero en este caso la señalización es SIP/UDP_TCP 5060 y la media el rango 6000 – 6500

Configuración Básica de Seguridad

Antes de entrar en la configuración básica del SBC sera necesario que veamos en AZURE que la configuración del Firewall permitirá el tráfico entre los puertos y direcciones que necesitamos. Para ello haremos lo siguiente:

  • Entramos en portal.azure.com
  • Vamos al “Grupo de Recursos” donde tenemos el SBC desplegado

Part 3_002

  • Seleccionamos la interfaz de red “eth 0”
  • Dentro del menú de propiedades seleccionamos “Reglas de Seguridad Vigentes”Part 3_003
  • Ahora nos aparecen todas las reglas de Seguridad de Firewall, tanto de entrada como de salida

Part 3_004

Desde aquí podemos comprobar según los datos que tenemos previos si la configuración de seguridad nos permitirá el trafico por los puertos y con los protocolos que hemos definido en el diseño, este es un paso importante que nos ahorrara muchos quebraderos de cabeza a la hora de registrar el SBC tanto en Teams como con nuestro Operador de SipTrunk.

En este apartado podemos limitar más la comunicación y seguridad, las reglas por defecto son genéricas, pero podemos tanto modificando el Firewall de Azure, como el propio que trae el SBC para añadir solo las direcciones IP necesarias en la comunicación y que el resto se descarte. Para ello realizare un artículo especifico de Seguridad.

A continuación, veremos la configuración Básica de seguridad en el SBC:

  • Entramos en el sbc emeasbc.zertia.es
  • Vamos al menú, Setup / Administration / Web & CLI y seleccionamos CLI SettingsPart 3_005
  • Dentro de la configuración deshabilitamos “Embedded Telnet ServerPart 3_006

NOTA: Cada cambio de configuración nos pedirá hacer un “Save” después d realizar, esto es necesario para terminar de aplicar el cambio

Part 3_007

  • Ahora vamos al menú Setup / Signaling & Media / Core Entities y seleccionamos SRDs
  • Seleccionamos el SRDs por defcto, y en Registration ponemos:

Part 3_008

Configuración NTP

Ahora vamos a ver cómo podemos configurar correctamente el NTP, este apartado es importante, es necesario que el SBC tenga correctamente la fecha y hora para el registro del Enrutamiento directo de Teams.

Para configurar el NTP vamos a:

  • Seleccionar SETUP / ADMINISTRATION y entrar en TIME & DATE
  • Habilitar el NTP y poner la dirección IP, en mi caso como el SBC tiene salida a Internet he puesto el NTP del Ejercito, en el caso de que el SBC lo tengamos en un entorno On-prem, podremos poner el NTP local que suele ser un controlador de dominio, en este caso habrá que asegurarse de que los puertos y protocolo NTP este abierto y haya comunicación con el mismo.

Part 3_009

  • Comprobaremos que la configuración es correcta viendo en Time Zone que la hora y fecha está bien.
  • En el mismo apartado podemos habilitar “Daylight Saving Time” donde podremos configurar el cambio de horario de verano e invierno

Part 3_010

NOTA: Antes y después de cualquier cambio de configuración se recomienda guardar una copia del Fichero de configuración *.ini

Part 3_011

Parte II: Microsoft Teams DR en Azure – Despliegue y configuración del SBC en Azure

Posted on Actualizado enn

DESPLIEGUE DE AUDIOCODES SBC VE EN AZURE

En el siguiente articulo vamos a explicar como desplegar nuestro SBC de Audiocodes en AZURE, para ello deberemos seguir las siguientes instrucciones:

Part 2_001

  • Vamos a Todos los servicios, y después buscamos Marketplace (All services > Marketplace).

Part 2_002

  • Buscamos “Mediant VE Session Border Controller (SBC)” y después pulsamos en “Crear

Part 2_003

  • Lo primero de todo, deberemos rellenaremos la configuración básica del SBC, nos basaremos siempre en el diseño y arquitectura inicial.
    • Virtual Machine Name: emeasbc
    • Username: sbcadmin
    • Contraseña: *******
    • Suscripción: Visual Studio Enterprise – MPN
    • Grupo de Recursos: SBCRESOURCES
    • Ubicación: Oeste de Europa

Part 2_004

Part 2_005

NOTA: En este caso, debemos tener en cuenta varios aspectos, por ejemplo:

El usuario y clave que creemos durante el despliegue sustituye al usuario Admin por defecto que trae las implementaciones on-prem de Audiocodes.

Para más información de las suscripciones de azure visitar el siguiente enlace https://docs.microsoft.com/es-es/azure/azure-subscription-service-limits

Para más información sobre las ubicaciones de Azure, visitar https://azure.microsoft.com/es-es/global-infrastructure/locations/

¿Qué es un grupo de recursos en Azure? https://docs.microsoft.com/es-es/azure////azure-resource-manager/resource-group-overview

  • Ahora, vamos a configurar las opciones avanzadas:
    • Capacidad de nuestra máquina virtual: Aquí según nuestra suscripción tendremos limitaciones, pero es cierto que el SBC es capaz de funcionar con una maquina de no mucho rendimiento. Yo en este caso, mi recomendación es ir a algo medio, pero eso sí, hay que tener en cuenta las limitaciones del fabricante. Por ejemplo: Si necesitamos transcoding sera mejor poner al menos 2 CPU. Mi recomendación en estos casos es que el rendimiento de la maquina no es necesario que sea el mejor, pero quizás si es bueno invertir mas en Alta Disponibilidad (HA) o en las comunicaciones.
    • Habilitar o no “Boot Diagnostics”

NOTA: Si algo es destacable en una implementación en Azure es la capacidad de escalabilidad o lo que llamamos “elasticidad” esto quiere decir, que podemos empezar con un SBC básico para los 60 usuarios de nuestra implementación con quizás 10 o 20 sesiones sería suficiente, y después podemos ir aumentando las capacidades de nuestra maquina según vayamos necesitando más recursos.

Es recomendable leer previamente al diseño las Realease Notes de las últimas versiones de SBC Audiocodes

https://www.audiocodes.com/media/13231/sbc-gateway-msbr-series-release-notes-ver-72.pdf

Part 2_006

  • El tercer paso sera configurar la Red, basándonos en el diseño inicial. Lo mejor en estos casos es configurar el grupo de recursos y las redes antes del despliegue, pero también podemos ir haciéndolo según vayamos desplegando la máquina.
  • Crearemos la red Virtual 10.0.0.0 /16

Part 2_007

  •  Ahora crearemos las subredes, la que nos conectara con el SipTrunk que hemos llamado VoIP y la de Direct Routing que es la subred de Teams.

Part 2_008

  • Ahora marcaremos la IP publica como “estática” en este caso nos configura la IP de la Subnet de Teams, después veremos cómo habilitar la otra red

Part 2_009

  • De manera opcional podemos cambiar el DNS con el que aparecerá dentro de Azure nuestra maquina

Part 2_010

Una vez terminemos la configuración y pulsemos en Aceptar, veremos el resumen de toda la configuración y podremos comprar el SBC

 

ASIGNAR UNA IP PUBLICA AL INTERFAZ SIPTRUNK

  • Desde el portal de Azure, vamos a “recursos” y entramos en el grupo de recursos donde tenemos nuestra maquina SBC

Part 2_011

  • Seleccionamos el recurso, en este caso la tarjeta Ethernet1, ya que la 0 se configura por defecto en el primer despliegue

Part 2_012

  • Ahora seleccionamos “configuraciones IP” del menú de la izquierda

Part 2_013

  • Habilitamos la dirección IP Pública

Part 2_014

NOTA: Para acceder a la configuración y ver que se ha desplegado bien el SBC, con la dirección IP publica de la Interfaz Eth 0 desde un navegador entraremos al SBC

Part 2_015

En el siguiente articulo veremos los prerequisitos necesarios  para la configuración del SBC para la integración de Teams, (Puertos, Códecs, IP’s, Certificados, DNS, etc…)

Parte III: Prerrequisitos y configuración básica del SBC

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.