07-13-2022 08:30 AM - edited 07-13-2022 08:34 AM
We are getting an intermittent problem where the first number of the voice mail pilot is being put and the end.
The vm pilot is 9358995. When certain users press the vm button on the phone, it is dialing 3589959. Sometimes we can reset the phone and it will work again. Most of the time we end up replacing the phone.
Any ideas as to why it is doing this? Or suggestions to what I should look at?
CUCM 14SU1 (will be going to SU2 this week)
CUC 14 (will be goign to SU2 this week)
Phone firmware is 14-01-0201-171
07-13-2022 10:42 AM
Is it an SCCP integration or a SIP integration? If SIP, are there any transformation rules on the SIP trunk or in the device pool to which the SIP trunk is assigned?
07-13-2022 11:15 AM
It is an SCCP integration.
I have no transformation rules, translation patterns, or route patterns that would match this. It works if the user goes off hook and dials 9358995 or 8995. I would expect if it was a pattern that I had wrong it would impact it all the time. It only seems to happen when users press the VM button. I think the only reason I haven't had more complaints is because most users get VM via email. Only a small number are unable to do that.
07-13-2022 01:31 PM
What is listed as the VM pilot number in the default vm profile or the vm profile assigned to the number(s) in question?
07-13-2022 02:22 PM
The number listed in all of the VM pilots are the same, 9358995.
If I dial 9358995 from any phone at any time it will always go to voice mail. If I dial 8995, the system translates that to 9358995 and always goes to voice mail. The only time we get an issue is when we use the VM button.
I just went through all of my patterns (route and translation) and I don't see anything that would match the pilot number and transform it.
Here are my thoughts. When we press the VM button the phone dials 9358995 which it gathered from the VM settings on the line. Something is stripping the 9 from the front and appending it after the 5. The phone can't do that unless CM tells it to. So if CM is telling it to then there must be a pattern somewhere that is randomly matching. It happens intermittently but as I think of it that may not be completely accurate. We have many phones that are NOT doing this, their VM button executes the expected action. However, once a phone starts doing this it seems to keep doing it. We have tried restarting, resetting, unplug/plug-in, and factory resetting, but I don't recall these fixing it. Since I cannot find a pattern that would transform the dialed number, perhaps it is something in the phone firmware.
I am actually upgrading CUCM to 14SU2 tomorrow so maybe that will have some impact. I suspect a TAC case is going to be the next step to finding a solution.
07-15-2022 12:28 AM
@Chris Austin wrote:
We have many phones that are NOT doing this, their VM button executes the expected action. However, once a phone starts doing this it seems to keep doing it. We have tried restarting, resetting, unplug/plug-in, and factory resetting, but I don't recall these fixing it. Since I cannot find a pattern that would transform the dialed number, perhaps it is something in the phone firmware.
I am actually upgrading CUCM to 14SU2 tomorrow so maybe that will have some impact. I suspect a TAC case is going to be the next step to finding a solution.
Have you looked at RTMT traces of good and bad calls? That should show you at what step the issue occurs. Although I agree that reading those traces is a pain.
Also have you looked for anything in common with the problem phones, model, firmware version, hardware version etc. Anything in common on the problem phones and different from the good phones.
07-15-2022 06:41 AM
I have not pulled traces. I will work on that. All the phones are the same. The only thing that stands out is the Device Pool. However, this DP is a set of people that do not get voice mail in their email.
07-15-2022 11:40 AM
Are they calling or called party transforms associated with the problem device pool?
07-18-2022 06:30 AM
Here are a couple of entries that I found in the call logs for today.
bad
2022/07/18 07:01:31.498|CC|SETUP|155467278|155467290|2289354060|3589959|3589959|5e61728c00105000a00000a2896d5ba5|*
2022/07/18 07:01:31.503|CC|OFFERED|155467278|155467290|2289354060|3589959|3589959|SEP00A2896D5BA5|S0/SU0/DS1
good
2022/07/18 07:02:38.874|CC|SETUP|155467415|155467417|9354060|9358995|9358995|061bfe5500105000a00000a2896d5ba5|*
2022/07/18 07:02:38.918|CC|OFFERED|155467415|155467417|9354060|9358995|9358995|SEP00A2896D5BA5|CiscoUM1-VI2|061bfe5500105000a00000a2896d5ba5|*
It seems to me that the phone is actually dialing 3589959. For this instance I found 2 calls where the phone dialed 3589959 twice at 7:01 and then at 7:02 it went through correctly as 9358995.
I double checked translation patterns and I don't have anything that would randomly change 9358995 to 3589959. I'm wondering if it could be a timer that getting hosed up. I have put a speed dial on a phone with 9358995 and it works every time. The numbers only get transposed when users press the VM button.
07-20-2022 04:08 AM
The bad one is going to a T1/E1 of some sort (S0/SU0/DS1). Do you have 7 digit dial configured for outbound to the PSTN? I am betting that you do. It looks like you have some sort of overlap with a "9.". Look in route plan report for anything starting with a "9".
07-20-2022 06:21 AM
It is not hitting a 7 digit dial pattern. It is actually hitting [2-9]XXXXXXXXX. I know this for certain because the t1 it is going out is a LD trunk. However, it is only hitting this pattern because the system is seeing 3589959. It really shouldn't even hit that but that's something for another day. There is no pattern that will change the dialed number from 9358995 to 3589959.
This config has been in place for over 10 years and this issue has only started in the last 6ish months. It could also be since we upgraded to 14 in August of last year. I'm going to open a TAC case I try to update this post with a solution once we have one.
07-20-2022 08:06 AM
It has to be matching something other than your 10 pattern there because the digits it is sending to the T1 are length 7. It could be a pattern with a "!" in it which doesn't have a specified length.
07-13-2022 03:41 PM
I doubt that it version specific. I would look at DNA (dialed number analyzer) and see what it says. I bet there is a translation pattern you are matching or something like that which you aren't expecting to be in play.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide