Delay in applying a config, phone system does not answer


#1

After I make a config change, lets say, upload new voice prompt and apply it to an IVR, if i call right away to test, i get a “Number not assigned message” when dialing from my cell phone. But after about 60 seconds it works. Is this normal?
I am using firmware version 1.0.18.12 for a UCM6208

Thanks…


#2

I think that depend if anyone already in IVR, changes cannot be completed if someone use IVR.


#3

I believe this to be a bug as I also encountered the same thing.

Same firmware as you report.

Client asked me to change inbound route for a specific time (lunch) such that calls would go to an IVR instead of direct to VM box. They also asked for same thing for after-hours. Dialing in to test (5:00AM this morning), a wireshark shows 404 response (not found). Simply rebooting the UCM resolved the issue.

I have submitted ticket to support, but in meantime, I can only suggest to reboot the device and see if this causes it to work correctly.

I have also noticed that after saving and applying a settings change, that the system takes longer to implement the change even though the apply setting has appeared to have completed. I am still playing with this one as I don’t have any real data yet; only an observation.


#4

Ok as it seemed to happen only after i did the firmware upgrade… Thanks for replying i am glad i am not crazy…

Have a great day.


#5

404 suggest that it cannot find IVR number.
I say if possible: delete this IVR create new and set again.

Can be glitch in config files.


#6

I tried to recreate the scenario by changing the route from and IVR to an extension. This worked without issue.

I then changed it back to the original IVR, and again it worked without issue.

I then deleted the route and re-created the route using the same original routing for after-hours to an IVR and the 404 resurfaced.

However, this time I waited a couple of minutes and tried dialing again and this time the IVR worked as it should.

So, it appears that there is some delay between the time that the apply indicated completion and the time that the function actually comes into play.

It could be that perhaps I did not wait long enough the first time and the reboot forced it.


#7

Applied is only when function is not occupied.
So maybe system was still cleaning tables ?


#8

We have observed the same issue on UCM firmware versions post 1.0.13.14. Applying changes kills the ability to receive inbound calls for about 45 seconds or so. Outgoing calls are not affected. We primarily use Register trunks through Callcentric. Trunk registration stays firm and does not drop.

Some systems also seem to require a full reboot to accept incoming calls after applying changes - but only sometimes. So far it seems that this only occurs when the UCM is behind a Cisco Meraki firewall, but don’t take that verbatim.

If anyone figures this out, I would be really curious to find a fix, or at least an explanation…


#9

Do you see incoming invite or not ?


#10

Marcin, yes I have the same issue in latter firmware. When making changes to the routes (as an example) and then applying, there is a delay between the time that the UCM indicates applying (with their spinning icon) and when the indication goes away implying complete and when the UCM will start to process incoming calls. The INVITE arrives, but the UCM does not respond and the caller just waits. Waiting a bit seems to sort it out.

In process calls are not impacted and I do not think outbound calling is although I cannot recall specifically testing for this. I notice is most when altering anything in the path of an inbound call that affects the answer.

I have gotten used to it so not much of an issue, but it can be an irritant when you think the configuration is complete and should be working only to test and then not have it work as you initially think something went awry, when it only needed added time.

While I have no real insight into it, only an observation, my opinion is that the apply indicator is not lock-step to the actual configuration update and reload that is need to employ the new settings and that possibly given the number and complexity of the changes or existing configuration, the time needed to recover to functional status may vary, so I may see the impact for a short period while other may see longer or shorter.

Just a guess though, but did scare me a little when I first came across it.


#11

Well for sure after i make an “Apply” and i cal in the UCM does not pick up for at least 60 seconds and the called gets a voice prompt saying the the system received an error…

At the moment i am in deployment , so its not a killer for now…