Problems using Music on hold / Problemas al usar Música en espera

#1

hello,
I have a Synway Gateway which connects to the UCM6302 central with an extension to a GXP1610, I did all kinds of tests and everything went perfect, the problem arose yesterday and I am not able to know what the problem is, I could not solve it for the moment, Since this problem had never happened to me, I only suspect where the problem could come from but I am not sure.

Here’s the problem: When a customer calls and is in a call with an Operator, If the operator leaves the customer on hold with MoH, when he takes him out of the hold, the customer can hear the operator perfectly but the operator stops hearing the customer for complete. (This can happen on the first MoH attempt or the second time)

This obviously generates a very serious conflict, since it makes the operator look bad and customers tend to call again.

I categorize this problem in the UCM since I think the problem lies in the UCM, in some bad configuration, sorry if I made a mistake in the label.

Please if anyone has an idea why this happens, it would help me a lot.
I appreciate your time.

hola,
Tengo un Gateway Synway la cual se conecta con la central UCM6302 con una extension a un GXP1610, realice pruebas de todo tipo y todo anduvo perfecto, el problema surgio ayer y no estoy pudiendo saber cual es el problema, no pude solucionarlo por el momento, ya que nunca me habia ocurrido este problema, solo sospecho de donde podria provenir el problema pero no estoy seguro de ello.

Aqui el problema: Cuando un cliente llama y esta en llamada con un Operador, Si el operador deja al cliente en espera con MoH, cuando lo saca de la espera, el cliente puede escuchar al operador perfectamente pero el operador deja de escuchar al cliente por completo. (Esto puede pasar al primer intento del MoH o a la segunda vez)

Esto obviamente genera un conflicto muy grave, ya que deja mal visto al operador y los clientes tienden a volver a llamar.

Este problema lo categorizo en la UCM ya que creo que el problema radica en la UCM, en alguna mala configuracion, perdon si me equivoque en la etiqueta.

Por favor si alguien tiene idea de porque sucede esto, me ayudaria mucho.
Les agradezco su tiempo.

#2

Only way forward would be to do a packet capture to see what the underlying issue is

#3

I made a couple ofpacket captures but the support did not give me any answer.

#4

Support will take a while to get back to you… it might be due to a back log, but I am not Grandstream so can only assume.

#5

Check if packet have incoming voice. Use PCM codec only on trunk, then wireshark allow you you to listen this.

#6

I don’t know how to use whireshark unfortunately :frowning:

#7

You an share here on priv or wait for GS support.

#8

Your port forwards for 5060 and the RTP ports are not set.

#9

Do you mean at the UCM or on the phone?

#10

He is using a GSM gateway which is local to the UCM, no need to forward.

#11

To the UCM.

#12

my RTP Timeout and RTP MoH are 7200/7300.
would this amount of seconds be ok?
Do they influence according to the Telephone Line mine and of the provider?

#13

From the traces you sent me, there is no need. Those settings are used to disconnect the call in the event that there is no RTP received from the other end. Personally, despite them having no impact on what I saw in the pcap, there is no need to have it set that long.

You are basically telling the UCM that if I am put on hold (RTP MOH) and there is no MOH or the UCM does not receive any audio when talking should occur (RTP Timeout) for a period of 2 hours, that is OK leave the connection up. Only disconnect the call when the timeouts exceed the period.

#14

In the captures, can you see any trace that the operator does not receive the client?

#15

As stated in my email, when you did the captures, you only selected one interface so I can only see the UCM and Gateway. I cannot see the extension. I can only say, that the audio streams between the gateway and UCM are constant and consistent. In the last pcap (5), I can clearly hear the other side throughout. While I may not hear the other side in all the captures, the stream is there, but the other side may not be talking or making noise.

This is why I need you to do a trace using all interfaces so I can see the extension as well. When making the call, do some talking so I can tell.

At the moment, the issue does not seem to be with the UCM, but without the full picture of all sides, it can’t be certain.

#16

Good morning, I’m just going to update the problem.

I was able to communicate with the Grandstream technicians in my area, unfortunately we still haven’t found the “why” of the error.
But we were able to get around the problem by setting up a couple of things on the GXP1610s.
Mainly the problem lies in the SIP Transport, when it is TLS the problem is clearly seen, but changed to UDP, it is solved despite the fact that it is not the viable option. (The strange thing, this only affects the GXP1610, since I have a GXP2160 with TLS and the error does not occur).
In addition to changing the SIP Transport, we changed the NAT Traversal, which was previously in STUN and now we disable it.

With these changes you can get past the problem although it is not the recommended option, I only attach this in case someone has a similar problem. This may be of some help to you.

I will wait for more tests with the technicians if they manage to find another solution or what the problem is.

Cheers!