Ignite Hanging/Stuck Calls 1

[Rich Mckevitt]

Hi - We seem to be getting agents having stuck/hanging calls sat on Ignite, sometimes for over an hour after the call actually ended. This is causing issues as it is stopping teh EHDU Agents making outbound calls. Is there anyway that these calls can be killed manually?

We are running MiVB v 9.1 SP2 with MICC v9.3

Cheers

Rich

Many thanks Richard

 

[Billz66]

Assuming web ignite - what browser is being used ?
there were lots of chrome related issues

If I never did anything I'd never done before , I'd never do anything.....

 

[Rich Mckevitt]

They are using Edge as a rule and yes for Web Ignite. I have tried to Busy the PLID and then done a RTS on the PLID and that doesnt work.

I have also tried going on the MiContact Center Config API under the /api/v1/diagnostics/router page and used the command
{
"commandName" : "clearagentstate",
"value" : "77524"
}
but I get an error
{
"message": "An error has occurred.",
"exceptionMessage": "An error occurred while sending the request.",
"exceptionType": "System.Net.Http.HttpRequestException",
"stackTrace": " at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Mitel.MiccSdk.Services.HttpClientService.<SendAsync>d__c.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Mitel.MiccSdk.Services.HttpClientService.<SendAsync>d__3.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Mitel.MiccSdk.Controllers.DiagnosticsController.<PostRouterCommand>d__19.MoveNext()",
"innerException": {
"message": "An error has occurred.",
"exceptionMessage": "Unable to connect to the remote server",
"exceptionType": "System.Net.WebException",
"stackTrace": " at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)\r\n at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)",
"innerException": {
"message": "An error has occurred.",
"exceptionMessage": "No connection could be made because the target machine actively refused it 172.30.41.65:5029",
"exceptionType": "System.Net.Sockets.SocketException",
"stackTrace": " at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)\r\n at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)\r\n at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)"
}
}
This was done on the actual remote server though?!

Many thanks Richard

 

[Billz66]

I completely missed the bit where you mentioned EHDA

what are the resieze timers set to for the cos of the trunsk and the agents

I had a similar issue where they were at the default of 300s - dropped them to 30
that means if acd call tries to deliever to ehda and the associated external number is busy it will set the EHDA to be unavailable for the length of the reseize timer


If I never did anything I'd never done before , I'd never do anything.....

 

[Billz66]

i think you can see this status using the Contact centre client on the server

if you open an agent monitor and select the EHDA agents
you should be able to set an alarm for make busy reason code resieze timer

add a threshold of 0 and then set the 00:00:01 or greater background to be red with white font

this should make them stand out if any of the EHDA agents are in the reseize state


If I never did anything I'd never done before , I'd never do anything.....

 

[Rich Mckevitt]

It is actually happening to non EHDU Users as well now - again mainly when they are working at home on Micollab so maybe network related but has also happened to office based workers in the past. I will take a look at the CCC on the server next time we have this issue with an agent and come back to you.

In regards to the reseize timers they are all set to 30 seconds as default.

Cheers for the help

Many thanks Richard

 

[Valamagules]

Have you checked this KB article -

http://micc.mitel.com/kb/KnowledgebaseArticle52664.aspx?Keywords=hotfix

Clever men learns what Wise men shares!

 

[Rich Mckevitt]

Cheers for this - I will take a look at the details for the Hotfix

Rich

Many thanks Richard

 

[sarond]

Be very careful with that hotfix, it is for SIP only. Read the RED it will cause serious errors on MiVB

I am having the same issue with a customer so if you find a solution please share.

 

[Rich Mckevitt]

Well we have just had advice from Mitel to upgrade to the 9.4.0 MICC. They have said that this will resolve hanging calls (I dont entirely believe that). It will also resolve another issue we have around the Micolalb Client Softphone disconnecting randomly and putting agents back to Start of Shift. We are about to enter our xmas Change Freeze so it will be one for the new year. I have found previously that whilst an U/G will fix one issue - it seems to throw up other issues.

If any changes are made then will post on here. It would be much easier if Mitel allowed us to kill a hanging call via Maintenance Commands or something similar!

Many thanks Richard

 

[Billz66]

yep 2 steps forward and sometimes 8 back with upgrades Especially with MICC .

The MiCC Director has just left and gone to google , perhaps the replacement might finally start fixing some of the endless QA issues they have with new releases

If I never did anything I'd never done before , I'd never do anything.....

 

[Rich Mckevitt]

Fingers crossed - I would love a day with the MICC & Ignite teams to find out why you cant do simple things !!

Many thanks Richard

 

[Valamagules]

MiCC is going out the door soon from what I heard. Just as they did with MiVCR.
Hopefully sooner than later if you ask me.

Clever men learns what Wise men shares!

 

[Billz66]

depends what they bring in to replace it
MIR isnt as quick and easy to configure as MiVCR was and is more expensive

If I never did anything I'd never done before , I'd never do anything.....