V20 upgrade routing issue

[lyje1]

Hi,

Upgraded a client site to v20. They have an IVR menu, for example, press option 6 for support dept, it plays the on-hold music (15 secs) until that ext phone user picks up otherwise after 15 secs, the voicemail kicks in. Since the v20 upgrade, the press option 6 goes straight to voicemail more often than not, 95%. This can be for any of the options in the IVR.

So if I test the IVR today, I could get the ext user pickup the call from me (external call) 3 times out of 20 call attempts. There's no pattern to it and there doesn't seem to be anything in the log files either.

The calls that fail and go straight to voicemail do not show up in the call logs. The rare time it goes through to the ext. user, it shows it in the call log.

Thanks,

 

[SteveITS]

Raise the log verbosity and test, it should show why it is being sent wherever it is sent.

Is option 6 sending to a ring group? Is this the only user in the ring group?

 

[lyje1]

All the IVR options go to a ring group extension. Some like Option 6 goes to a prioritise hunt (Goes to the first user and overflows to second user) other Options go to ring group with 'ring all'.

The strange thing is in the call logs and dump.pcap logs, all the 'failed' calls don't get logged. The log verbosity is at the highest level. The 'failed' calls is where we dial in, hear the IVR, select an option, it kicks in the voicemail instead of ringing the ring group user for 15 seconds. The only time it logs the calls is where it works. Dial in, IVR, option, ring group user picks up the call.

 

[SteveITS]

Are you filtering/searching the verbose log? My first thought would be that somehow you're not calling what you think you're calling.

We picked up a 3CX client who complained their IVR didn't work when they pressed keys...turns out they were playing the IVR prompt on the "When office is closed route to" option, before sending the call to the IVR, where it played again.

 

[lyje1]

Thank you, your comments nudged me in looking at the AWS instance. With the v20 upgrades, we normally create a new instance, take the public IP address from the old instance, upgrade to v20 and then stop the old instance. When we double checked everything, we notice we didn't stop the old instance. This was the cause of our issue. For some reason, the majority of calls were still routing to the old v18 instance but then other calls would route to the new v20 instance. Hence why in the log files it wasn't showing the failed calls as it was hitting the old instance. Still not sure why it was caching the routing to the old instance when it had a new public IP address assigned?

 

[NicholasP_3CX]

Every few minutes a SIP Provider connection in 3CX will reREGISTER on the provider. So having your SIP trunk configuration on multiple machine will cause these intermittent issues.

This is why some calls are going to the old machine.