SIP

ms-diagnostics:33038 reason “Cannot transfer the call to another pool” and Conference ID not Found (English)

Posted on Actualizado enn

Hello all,

Again here, with one of those curious mistakes this time one of those of a global topology there are two “Skype sites” with two “Front-End Pools” separated by a dedicated network for the customer, such as an MPLS network for example.

DESIGN:

We have this design:

diagrama-general

We have two Site in Skype for Business, one in “SPAIN” and another in “UK” linked by a dedicated network, the two sites have their output to the local PSTN through “Gateway / SBC” and its corresponding Mediation Server, all right here.

PROBLEM DETECTED:

The client uses much the service “Skype Conference Call”, because in some of its offices still are not migrated to Unified Communications and has VoIP PBX, in this case all audio conferencing service is housed in one of the Front End Pool, specifically in the UK that houses all accounts “Dial in Access Number“.

El Servicio Doméstico “Dial in Access Number” se encuentra en el Pool del Reino Unido y el Conference ID se puede alojar en el Spain Pool y el Reino Unido.

  1. A user in Spain, creates a conference with Conference ID. 60051
  2. He sends the ID to the contacts for the meeting
  3. A UK User connected to the PSTN dials the number “Dial in Access Number” of UK with number +44 20 7234XX XX to enter the meeting
  4. The user dial the Conference ID 60051 and receive the following message “sorry, I can not connect to your meeting right now“.

When the call is received by “Dial in Access Number” in the UK and the Conference ID was on the Front End SPAIN this error occurred.

PROBLEM SOLUTION:

diagrama-error

To solve the problem, the first thing we can put a trace with the “logging tool” in the Front End pool of UK and launch a test.

We could see the following error:

error1

“Cannot transfer the call to another pool”

To solve this error simply change the parameter “Refer Support” to False

Set-CsTrunkConfiguration -Identity (Trunk_Name) -EnableReferSupport $false

solucion

After changing the Enable Support Refer parameter to “False” in the UK Pool was able to connect the call audio conferencing service with the conference ID of the user Spain Pool

diagramasolucion

ms-diagnostics:33038 reason “Cannot transfer the call to another pool” and Meeting ID not Found

Posted on

Hola a todos,

Otra vez por aquí con uno de esos errores curiosos que se encuentra uno en las implantaciones de topologías globales en las que hay varios “SITES” con diferentes Front-End Pools separados por una red dedicada para el cliente, como puede ser una red MPLS por ejemplo.

DISEÑO:

Partimos del siguiente diseño:

Diagrama General.jpg

Tenemos dos Site en Skype for Business, a nivel Topología, uno en “SPAIN” y otro en “UK” unidos por una red dedicada, cada infraestructura tiene su salida a la PSTN local por medio de Gateway/SBC y su Mediation Server correspondiente, hasta aquí todo correcto.

PROBLEMA DETECTADO:

El cliente tiene costumbre de uso el servicio de “Audioconferencia” de Skype, inlcuso de forma interna, ya que en algunas de sus sedes aun no están migrados a la solución de Comunicaciones unificadas y tiene PBX de VoIP, en este caso todo el servicio de Audioconferencia esta alojado en uno de los Front End Pool, concretamente en el de UK siento este el que aloja todas cuentas del “Dial In Access Number“.

De esta manera nos encontramos que el Servicio Principal “Dial in Access Number” esta el Pool de UK y en los ID de conferencia pueden estar alojados tanto en el propio Pool de UK como en el de SPAIN.

Es aquí donde nos encontrábamos el problema:

  1. Un usuario del Pool de Spain, crea una conferencia con el ID de conferencia. 60051
  2. Este envía la convocatoria a los contactos para la reunión
  3. Un usuario de UK conectado a la PSTN marca el numero “Dial in Access Number” de UK con numero +44 20 7234 XX XX para entrar a la reunión
  4. Marca el ID de conferencia 60051 y recibe el siguiente mensaje “sorry, I can’t connect to your meeting right now“.
  5. Y se cuelga la llamada

Cuando la llamada entraba por el “Dial in Access Number” de UK y el ID de conferencia estaba en el Front End de SPAIN se producía este error.

SOLUCION DEL PROBLEMA:

diagrama-error

Para solucionar el problema, lo primero que hicimos pue poner una traza con el “logging tool” en el Front End de UK y lanzar una prueba.

Pudimos ver el siguiente error:

error1

“Cannot transfer the call to another pool”

Para solucionar este error simplemente hay que cambiar el habilitar el parámetro “ReferSupport”

Set-CsTrunkConfiguration -Identity (Trunk_Name) -EnableReferSupport $false

solucion

Una vez cambiado el parámetro EnableReferSupport a False el Pool de UK era capaz de conectar la llamada del servicio de audio conferencia con el ID de la sala del usuario del pool de España

diagramasolucion

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.