When the unit is rebooted the last saved configuration is loaded. If changes were implemented but never saved that could cause a unit to not function the same way it did previously. That may not be the problem from your situation, but it is worth mentioning. If you are using DIDs I would recommend you check the configuration to see if the DIDs, aliases, or SIP identities (depending on how your specific configuration was implemented) are present in the corresponding voice users, auto-attendants, ring groups, etc . If they are configured correctly the next thing to check is that the phone is booting up properly and registering. If you see it listed under Voice > Reports > SIP Registration List the phone should be ok. After the configuration and the phone have been checked the next step is a debug. I would be happy to review your configuration and the output from a debug voice verbose and debug sip stack messages while the problem is recreated if you can supply them. You would need to remove any sensitive information (passwords, public IPs, public phone numbers, etc) before supplying them in a reply. You can alternatively upload them to our FTP server from the instructions below:
Open Internet Explorer web browser
Type the following URL: ftp://ftp.adtran.com
Double-click the "Incoming" folder
Drag and drop files from PC into the Internet Explorer window
If you place files on the FTP server I would need to know the file names in order to retrieve them.
I see you opened a support ticket with us on this issue. It was recommended to change the existing call flow to go to directly to the receptionist with a DID on the voice user or a virtual user instead of to a ring-group that only has the receptionist as a member. It was also suggested to setup a persistent debug in case the problem happens again. Since a support ticket is already open, please continue working with us that way. After the issue is resolved please come back to this post to update it so others can benefit from the solution.
We did not want to change the call flow. It gives the customer the ability to add users in the future to the ring group to receive calls without having to change call coverages. After submitting the 120MB debug file to support Charles was able to identify the issue. The command to allow a ring group member to have call waiting was not present. I am unsure how this happened since the customer has been using the system for over a year and no issues came up until I upgraded from 403 (initial post says 408 but it ws 403) to 412 and I am certian the call waiting was there previously. I simply added the command and problens resolved.
voice user XXXX
this allows a member of a ring group call waiting.