Abandoned Calls Continue to ring.

[concs]

Does anyone else see that when a caller to a queue hangs up before reaching an agent, the inbound call continues in the queue until it is picked up by an agent (who hears a dead line)?
This only happens with queues, as inbound calls directed to an extension or a ring group stop ringing (and the line is released) moments after the caller hangs up.

Surely one would not want abandoned calls to remain in the queue and need an agent to end them.
This behavior is the same for calls incoming from PSTN gateways or VoIP providers.

Is this a bug or peculiar to my setup? It drives me crazy!

 

[willow]

I have not seen thus issue as of yet. I have tested it on my v10 and it works as it should.

 

[concs]

Thank you for that. I guess it must be my setup for some reason. Now to try and find why!!!
Any ideas would be greatly appreciated.

 

[SY]

Thank you for that. I guess it must be my setup for some reason. Now to try and find why!!!
Any ideas would be greatly appreciated.

You need to check following scenario for the calls received from PSTN line and from VoIP provider.

1. answer incoming call
2. Talk to caller
3. Ask caller to terminate the call and then wait until your phone will show that the call has been disconnected (don't put headset on hook, just wait)

How long the phone shows that the call is still connected?
Are there any differences for the calls received from PSTN line and VoIP provider?

this test will help to localize problem

Regards

 

[eagle2]

This seems to be a NAT/firewall issue - some SIP packets are not transmitted / received by the phone.
Try capturing the traffic to the phone with Wireshark, etc.

 

[willow]

are the calls coming in on an analog line or sip trunks? if its a sip trunk then you may want to make sure that the when the line is disconnected, meaning the outside caller hangs up, that the port is going idle. it may be a disconnect issue with the line and port settings.

 

[concs]

Most calls to the queue come through a PSTN gateway (grandstream 4108) but the same problem occurs on incoming VoIP lines.
And only queue calls do it, weird.

 

[concs]

I am informed that this is "normal".
The queue acts as an extension and "transfers" incoming calls to the operators. If the caller hangs up, the "transfer" persists until an operator picks it up (and hangs up) to end the transfer.
Can this possibly be right. Could someone try this for me please?
Call the queue from an external number and hang up once in the queue.
I tested out of hours and the queue continued to "ring" 20 minutes after I hung up. (then I killed the call).

If this is the way it works I find it rather unsatisfactory.

 

[SY]

I am informed that this is "normal".
The queue acts as an extension and "transfers" incoming calls to the operators. If the caller hangs up, the "transfer" persists until an operator picks it up (and hangs up) to end the transfer.
Can this possibly be right. Could someone try this for me please?
Call the queue from an external number and hang up once in the queue.
I tested out of hours and the queue continued to "ring" 20 minutes after I hung up. (then I killed the call).

If this is the way it works I find it rather unsatisfactory.

Simple test which will show you how queue should work.
Don't use PSTN or Voip provider. Simply make call from any local extension to the queue. Queue manager will start to poll agents. Terminate the call. All phones will stop to ringing immediately.
It is how it works.

Regards

 

[concs]

Simple test which will show you how queue should work.
Don't use PSTN or Voip provider. Simply make call from any local extension to the queue. Queue manager will start to poll agents. Terminate the call. All phones will stop to ringing immediately.
It is how it works.

Regards

Couldn't agree more. That is exactly how it should work. And it does work that way from an internal extension.
Not many calls to the queue are from internal extensions, unfortunately, and that is not how it behaves from external calls PSTN or VoIP.

 

[SY]

Briefly:
FXO port settings don't correspond parameters of physical line. As result, PSTN gateway doesn't detect "end of call".
Why it is happening with VoIP provider is not clear. Most likely NAT/firewall is not properly configured.

Please provide information about PSTN gateway (manufacturer, model, firmware), physical line (type, location[country], provider) and VoIP provider (name, country)?

Thanks

 

[eagle2]

Grandstream's VoIP gateways are not disconnecting calls immediately after hang-up.
This is 'normal' behavior when CPC or polarity-reversal are not applicable.

From my experience Cisco/Linksys SPA-3102 (SPA-8800) gateways are more reliable -- there are more criteria based on impedance, long silence, etc.

Regards

 

[concs]

Looks like a gateway to queue problem. I got a new voip acccount with a different provider to the (Temp.) one I was using and it ends a queue call as soon as caller hangs up, so 3CX is dealing with that perfectly. Why the old VoIP account did not is a mystery but as others have said may be unrelated to the main problem which is calls through the gateway.

I AM using a Grandstream 4108 Software Version: Program--1.3.4.10 Loader--1.1.3.4 Boot--1.1.3.2 .
I have also tried the gateway with Firmware 1.3.1.6 to no avail. (I'll put that back if it will help)

I am in Australia, the incomming lines are Telstra lines.
I am unable to get Current Disconnect to work.
Tone disconnect sems to work fine except if the call is going to the queue.

 

[nb]

The gateway has to be configured correctly according to the settings of

A) your country B) Your telco C) the Grandstream gateway.

So you have to call your telco, and basically ask them to help you fill in the Grandsteam gateway device pages with the things that you do not know.

Then when it is configured correctly you will see that when you disconnect a call, the Telco will pass the disconnect frequency to the Grandstream and instead of the grandstream not understanding it and treating it as normal voice, in this case it will drop the call.

When you see these basic things not working, contact either support departments but if you are in FXO environment first contact your telco for information.

Try and Calibrate the lines. See if that helps. You can contact Grandstream too for advice.

 

[concs]

Yes, that's the path I first went down, calibrated, changed tone settings to various recommendations for Australia, even tried different firmware versions on the gateway.
But the whole system performs flawlessly (hangs up straight away) as long as the call isn't in a queue. I then thought this must mean the gateway is ok?

I'll contact the Telco and see if they can tell me anything "official" and ask Grandstream as well.

 

[nb]

but what happens when it is in the queue?
i cannot see what diff it makes - in this scenario, if the disconnect tone is understood for a normal call by the gateway then it should also understanding it for a queue call.

I think you are not detecting which leg is not disconnecting because now you have another leg.

A) is the queue in waiting or connected?
B) simply make a wireshark capture and check whether the bye's are being respected. The one that does not respect the by is the fault. it can be the Gateway, the pbx, or the extension.

 

[concs]

OK looked at wireshark captures.
When incoming call to ring group or extension hangs up - the Grandstream sends a 'CANCEL'
When incoming call to a queue - the Grandstream sends NOTHING!

SO.. on the same line in via the GS4108 gateway
I set it to go to a ring group, ring for a while, then transfer to the queue.
If the incoming caller hangs up while hearing the "ringing" sounds - No problem. 'CANCEL'.
If the incoming caller waits until hearing the on hold music (is in the queue) then hangs up - Rings forever. no 'CANCEL'
So for some reason, if the Grandstream is passing on the Hold music, Tone disconnect does not work.
That got me thinking, so I tried, Hang up form On Hold and Hang up while leaving a Voice Mail.....

Caller hanging up at any of these does not prompt the Grandstream to end the call.
edit - Same if call is actually connected to (talking to) an extension, calling party hangs up extension stays connected.

 

[nb]

OK so now you are in a better position to tackle this. You need to open a support ticket - Direction Grandstream Support

 

[concs]

I'm on that now!
I'll post back with progress.

Thanks for the help.