ATM16 Issue 1

[r6wraith600]

I am running the latest IP 500 with an ATM16 IP 500 version all with the latest software release. (.11) and(.24)

A caller calls in, as they are listening to a menu prompt it will disconnect the caller/ or behave like the caller is hitting a button. I setup the invalid to repeat the menu to determine that it is what is happening. I disable tone interupt in that menu and it plays all the way through fine. So I am certain that is what the system "thinks" the caller is doing.

I have reloaded the firmware as well as grounded it(even though it's using earth ground power supplies). I can replicate this on specific lines within the module.

I have called in from this system from one line to another and watched teh trace log. The trace log shows that nothing is being pressed or occuring, yet it is behaving as proven above that is what is happening.

Any thoughts? I am at the clients site right now and I have tried just about eveything I can think of. I have gone as far as rebuilding the voicemail and the same issue is happening.

Thanks!

 

[kholladay]

Load up DbgView and see what Voicemail Pro thinks is happening.

http://www.ipofficeassistance.com

Click Debug View (When extracting I suggest the 1.0 version)

Under View>Debug Filters select vmprov5svc and choose "8 Trace" from the drop down.



Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[TheDoz]

I have had this happen in the past, I would try re-recording the Auto Attendant greeting and perhaps with a different voice or person recording it for starters.

"Religion is regarded by the common people as true, by the wise as false, and by the rulers as useful"
"The lack of money is the root of all evil"

 

[kholladay]

Even though it has nothing to do with this forum I give you a star for quoting Seneca.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[r6wraith600]

I have re-recorded eveything as I have experienced this as well, still didn't solve it.

As for the Dbgview? Where do I find that? I know about monitor and tracing through system status but that isn't showing me anything defniative. I have a ticket in with Avaya at the moment but I am waiting for a call back.

I am on site as this client needs this fixed and working asap so I am trying every resource I have avaliable.

 

[r6wraith600]

Oh Kholladay sorry I see you mentioned where that was I will check it out now, thanks....stand by for results.

 

[r6wraith600]

KHolladay.... sorry I figured you were refering to the filters withing Monitor....so where can I find Dbgview?

 

[r6wraith600]

Ha ok nm you wanted me to get this from your site....this is just a trace of the VM Service if you use it in interactive mode....so I will watch this then to see.

 

[r6wraith600]

Alright this is all it gives me... so I called in, hit the first menu then selected my an option "4" in this case...it was playing the menu and then it decided to transfer me off to my "0" out in this case even though I didn't hit anything.

Here is the Debug / VM Service log info for that section of the scenario.

- Internal: !Internal!=N
16:00:38.937 - Session: 00000104 - Configuring for known disconnect tone length of 0s
16:00:38.937 - Session: 00000104 - Configuring for unreliable disconnect setting IDLE time to 30.000s
16:00:38.937 - Session: 00000104 - Receive ACTIVE for session 00000104, call-id 355
16:00:42.546 - Session: 00000104 - Executing request to run node Short Codes.VMMain.Nurse Docs.0
16:00:42.546 - Session: 00000104 - Executing node Short Codes.VMMain.Nurse Docs.0
16:00:42.546 - Session: 00000104 - Executing request to run node Short Codes.VMMain.Nurse Docs.1
16:00:42.546 - Session: 00000104 - Executing node Short Codes.VMMain.Nurse Docs.1
16:00:42.546 - Session: 00000104 - Executing request to run node Short Codes.VMMain.Nurse Docs.Body.0
16:00:42.546 - Session: 00000104 - Executing node Short Codes.VMMain.Nurse Docs.Body.0
16:00:47.312 - Session: 00000104 - Executing request to run node Short Codes.VMMain.Nurse Docs.Invalid.0
16:00:47.312 - Session: 00000104 - Executing node Short Codes.VMMain.Nurse Docs.Invalid.0
16:00:47.312 - Session: 00000104 - Executing request to run node Short Codes.VMMain.Nurse Docs.Invalid.1
16:00:47.312 - Session: 00000104 - Executing node Short Codes.VMMain.Nurse Docs.Invalid.1
16:00:47.312 - Session: 00000104 - Executing request to run node Short Codes.VMMain.Transfer To Main.0
16:00:47.312 - Session: 00000104 - Executing node Short Codes.VMMain.Transfer To Main.0
16:00:47.312 - Session: 00000104 - Executing request to run node Short Codes.VMMain.Transfer To Main.1
16:00:47.312 - Session: 00000104 - Executing node Short Codes.VMMain.Transfer To Main.1
16:00:47.328 - Session: 00000104 - SetTransfer=200
16:00:47.328 - Session: 00000104 - GetTransfer=200, client_info is true
16:00:47.328 - Session: 00000104 - SetTransfer=(null)
16:00:47.343 - Session: 00000104 - Configuring for known disconnect tone length of 0s
16:00:47.343 - Session: 00000104 - Configuring for unreliable disconnect setting IDLE time to 30.000s
16:00:47.343 - Session: 00000104 - Receive CLOSE for session 00000104, call-id 355

 

[r6wraith600]

So when it works normally this is what I see.


16:23:55.968 - Session: 00000131 - - Internal: !Internal!=N
16:23:56.968 - Session: 00000131 - Configuring for known disconnect tone length of 0s
16:23:56.968 - Session: 00000131 - Configuring for unreliable disconnect setting IDLE time to 30.000s
16:23:56.968 - Session: 00000131 - Receive ACTIVE for session 00000131, call-id 451
16:24:05.093 - Session: 00000131 - Executing request to run node Short Codes.VMMain.Nurse Docs.0
16:24:05.093 - Session: 00000131 - Executing node Short Codes.VMMain.Nurse Docs.0
16:24:05.093 - Session: 00000131 - Executing request to run node Short Codes.VMMain.Nurse Docs.1
16:24:05.093 - Session: 00000131 - Executing node Short Codes.VMMain.Nurse Docs.1
16:24:05.093 - Session: 00000131 - Executing request to run node Short Codes.VMMain.Nurse Docs.Body.0
16:24:05.093 - Session: 00000131 - Executing node Short Codes.VMMain.Nurse Docs.Body.0


So that is a good help / tip to determine what the Vm is seeeing as it showed me a bit more. The problem still lies.....why does it think it's triggereing something?

 

[Westi]

Did the recording have a female voice and did the same person rerecord it?
I had a colleague and she was not able to record the greetings as half of them triggered these types of errors, if you have a female voice doing the recording try a male voice even if just for testing purposes.


Joe W.

FHandw., ACS

If you can't be good, be good at it!

 

[r6wraith600]

Yep it was a female voice and I am male. Same issue. After some time with Avaya they are thinking it's a mad ATM. I have to send some logs and traces for the Dev team to look at but that's where it is standing at the moment.

 

[kholladay]

The log received from running interactive mode does not show the same information you would receive from DbgView under Trace/High Trace. Would have been nice to actually see the DTMF tones and the duration of the tone. If you can consistantly repeat the problem and the tone's duration is the same every time it would indicate that the problem was with the recording in that the recording doesn't change. If the issue is a faulty ATM16 the duration may likely change.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M, TIA-CTP, MCP/MCTS Exchange 2007
ACE Implement: IP Office

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford