DTMF

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

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.