Something causes all extenstions to not able to call in or out fix is to resetall

I’m not sure what causes this

about once a year one of the users will change queue membership and apply config.

After that no extension in the system can call until I do a resetall on the extensions.


What info is needed to solve and prevent the outage.

No restore from backup is being done.

Just curious and to see what would help get a fix for this.

I’m using freepbx with current modules.

To effectively address and resolve any software issue, it’s crucial to replicate the problem consistently. Random occurrences that happen infrequently can be challenging to tackle. Developers need specific information to understand and fix bugs. Here’s a simplified guide:

  1. Describe the Problem:
    Provide a clear explanation of what went wrong. This includes detailing the failure itself.

  2. Explain the Expected Outcome:
    Clearly articulate what you expected to happen. This helps developers understand the intended behavior.

  3. Reproduce the Issue:
    Outline the steps to recreate the problem reliably. If a developer can follow these steps and consistently encounter the issue, it becomes much easier to diagnose and fix.

In your case, if, for instance, changing a queue and applying the configuration leads to extensions not working, the following information is vital:

  • Identify the specific change made to the queue.
  • Verify if repeating the same change consistently causes the issue.

Understanding the purpose of the ‘resetall’ action can also be insightful. It essentially writes user and device data to the astdb. If an issue arises after this action, it suggests that the data might be getting corrupted or removed.

You can examine the relevant code here and here. In essence, ‘resetall’ affects the astdb tables. If you can reliably reproduce the problem, you can compare astdb tables to identify missing information. This process helps pinpoint potential issues and facilitates a more effective resolution.

So as stated.

a user makes a queue change and does the apply config.

Phones will be registered but get no dial tone to make a call, on calling the phone the calls would go directly to Voicemail.

No error was located in logs files

Fix was to resetall extensions.

But this suggest the fix was in some process that uses astdb so is it a astdb issue?

What “Queue Change” is made specifically. There are dozens of queue settings…

Type of phones? how are they registering with the PBX: End Point manager? manual config on the phone local Gui? Clearly Devices Module? something else?

What do you mean by “resetall extensions?” specifically how did you do this?

These are the kind of specifics others need to understand and possibly reproduce your issue.

so There was a few queue members added as Dynamic queue members.

As well there was a change in phone number in a ring group.

So when they user that made the changes did an apply config in the freepbx GUI it likely caused something to get deleted or changed in the astdb database. We don’t know this for sure this the working theory.

Phones are either Bria, or webrtc phone using Jssip. We don’t need a provision manger as those are configured in Stretto console for Bria or in the Loway interface in Queuemetrics. So think of this as manual provisioned.

The command to reset all extension (rebuild them in the astdb) is


That web call will fire off a php script that takes data from the Mysql Asterisk config database and insert it into the AST DB Sqlite database.

so we know whatever is broken this is what fixes the problem. (From core/Core.class.php)

// this function rebuilds the astdb based on device table contents
// used on devices.php if action=resetall
function devices2astdb(){

	$devresults = $this->database->query("SELECT * FROM devices")->fetchAll(\PDO::FETCH_ASSOC);
	$uservoicemails = $this->database->query("SELECT extension, voicemail FROM users")->fetchAll(\PDO::FETCH_KEY_PAIR);

	//add details to astdb
	if ($this->astman->connected()) {
		foreach ($devresults as $dev) {
			if(trim($dev['emergency_cid']) != '') {
			// If a user is selected, add this device to the user
			if ($user != "none") {
				$existingdevices = $this->astman->database_get("AMPUSER",$dev['user']."/device");
				if (empty($existingdevices)) {
				} else {
					$existingdevices_array = explode('&',$existingdevices);
					if (!in_array($dev['id'], $existingdevices_array)) {
						$existingdevices_array[] = $dev['id'];
						$existingdevices = implode('&',$existingdevices_array);

			// create a voicemail symlink if needed
			if(isset($uservoicemails[$dev['user']]['voicemail']) && ($uservoicemails[$dev['user']]['voicemail'] != "novm") && $this->freepbx->Modules->checkStatus('voicemail')) {
		return true;
	} else {
		return false;

// this function rebuilds the astdb based on users table contents
// used on devices.php if action=resetall
function users2astdb(){
	$userresults = $this->database->query("SELECT * FROM users")->fetchAll(\PDO::FETCH_ASSOC);

	//add details to astdb
	if ($this->astman->connected()) {
		foreach($userresults as $usr) {
		return true;
	} else {
		return false;

Finding what breaks it is the hard part.

So the extension reset is outside of FreePBX then?

I know this isn’t very helpful but I only had one client using Bria and for years and it was a constant problem. Had to re-config or unblock them weekly. Switched them over to ClearlyAnywhere and all problems disappeared. Barely hear from them anymore for support.

So what was the reset you had to do?

I’m wondering if there is something in common.

no reset… the PBX Firewall intrusion detection was blocking the IP addresses of the Bria clients public IP. It happened randomly and could never find the reason. (Didn’t look too hard honestly, these people are offshored temp employees and extremely time comsuing to troubleshoot with…).

Anyway, once we switched them over to ClearlyAnywhere the blocking stopped.

Ok. thats different.

This seems like it is a issue with something that is infrequently done in freepbx. I don’t know what but something.
It corresponds to a change in ring groups config and the apply config button.

This is going to be a tough one for my Root cause anaysis meeting. So what happened , it broke. Why I don’t know. I hate those meetings.

the blocking of IP’s was just one of the issues. There were also plenty of times I had to just totally re-configure the Bria client to get it to connect again. I’m sure plenty of people have Bria working fine, personally, not a fan. The ClearlyAnywhere app has been flawless so far.

That said, sangoma connect has worked well also in the past.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.