Outbound calls broken after Time Conditions change

Ok, here is the scoop.
I added an IVR to our system for after hours. Everything seemed to be working great, until the IVR became live. As soon as our Time Conditions switched over to using the IVR, our Outbound calls are no longer working. It looks like the FreePBX system is not even sending any registration or even our credentials properly to Vitelity (our VOIP provider), and so they are showing our Outbound account as Not Registered. Come time for our Time Conditions to not use the IVR and our Outbound calls are working. Obviously something is messed up with the Time Conditions or Time Group but I have no idea what I can check with this. I understood that Time Conditions were linked to Inbound calls only, but apparently they are also linked to Outbound somehow.

Here are the specs on my software.
PBX Firmware:12.7.4-1710-2.sng7
PBX Service Pack:

Any help with figuring this out, would be greatly appreciated.


Check your outbound route for a Time Group setting. There have been 2 14 users over the last few months that have complained about something like this.

That is the first thing I checked, but my one and only outbound route is set as a Permanent Route and has never had a Time Group assigned to it that I am aware of. I don’t ever want it associated with a Time Group either as the one and only time group is only for Inbound calls for our system.

Neither had the other two. Search back through the forum for “Permanent” and “Time Group” and you should find a couple of threads of people saying “That can’t possibly be it” only to find that it was.

I created a brand new Outbound route, created a brand new time group that covered all the times that the other time group we use did not, and assigned that to this new Outbound route. Made sure all the Extensions were allowed to use that route, and viola everything is working. It appears that there is a bug in either the outbound route module and/or the time groups module. That “Permanent Route” feature does not work as it is supposed to.

It is much more subtle than that. There are 2 or 3 users reporting this out of thousands. I have tested repeatedly, and I can’t reproduce. What is the output you get from:

asterisk -x "dialplan show outbound-allroutes"
> asterisk -x "dialplan show outbound-allroutes"
> [ Context 'outbound-allroutes' created by 'pbx_config' ]
>   'foo' =>          1. Noop(bar)                                  [pbx_config]
>   Include =>        'outbound-allroutes-custom'                   [pbx_config]
>   Include =>        'outrt-3,08:00-17:00,mon-fri,1-31,jan-dec'    [pbx_config]
>   Include =>        'outrt-4,17:00-08:00,mon-fri,1-31,jan-dec'    [pbx_config]
>   Include =>        'outrt-4,00:00-23:59,fri-mon,*,*'             [pbx_config]

> -= 1 extension (1 priority) in 1 context. =-

So Asterisk thinks you have time groups set for all your outbound routes. If you have Permanent selected, they appear without any time info. Furthermore, outrt-4 appears twice in the list, not sure how you accomplished that, do you have 2 different outbound routes with the same ID?

Two separate time schedules in the same Time Group for outrt-4

How can I change it so that Asterisk does NOT have time groups set for outbound routes?

Choose Permanent in for the Outbound Route, and apply config. Then check Asterisk again, it should look like this.

[ Context 'outbound-allroutes' created by 'pbx_config' ]
  'foo' =>          1. Noop(bar)                                  [pbx_config]
  Include =>        'outbound-allroutes-custom'                   [pbx_config]
  Include =>        'outrt-2'                                     [pbx_config]
  Include =>        'outrt-4'                                     [pbx_config]
  Include =>        'outrt-1'                                     [pbx_config]
  Include =>        'outrt-3'                                     [pbx_config]

Just choosing the Permanent Route on both Outbound Routes does not change a thing.

You may need tp select something else before you switch it back to permanent. If there are no changes, I don’t think the options are updated.

 asterisk -x "dialplan show outbound-allroutes"
[ Context 'outbound-allroutes' created by 'pbx_config' ]
  'foo' =>          1. Noop(bar)                                  [pbx_config]
  Include =>        'outbound-allroutes-custom'                   [pbx_config]
  Include =>        'outrt-3,08:00-17:00,mon-fri,1-31,jan-dec,America/Denver' [pbx_config]
  Include =>        'outrt-4,08:00-17:00,mon-fri,1-31,jan-dec'    [pbx_config]

-= 1 extension (1 priority) in 1 context. =-

This is what happens when I change the time group to something save changes and then go back and change to Permanent Route. It seems to be taking that first Time Group no matter what I put.

On a slightly different note - this might be a good time to get a ticket going. Since it’s come up a couple of times before, there might be something that the developers need to look at.

Another quick question - what browser are you using? It might be a weird page cache interaction?

Using Google Chrome. However, I have done this same thing on a completely different computer that had never logged into the GUI before and it had the same outcome, so I highly doubt it has anything to do with the cache seeing as that had no cache.

I am new to asterisks please ignore if you find me irrelevant.
Trunking is achieved by dialing extension.
For example to set a remote location trunk I need an extension to dial. Say extension 5001 if this extension is reachable trunk is up.
All extensions are located in db.
In your case when your system try to set trunk up, time group setting’s route trunk extension to IVR rather than db hence you Trunk is Down.( reason for outbound call failure)
Any setting which exclude system based extension from time group setting would solve the issue.

If not then you have to log a call with dev team

Its a definite bug - if you choose permanent route then it uses the first time group that you added to the system

Include => ‘outrt-3,09:00-17:30,,,*,Europe/Dublin’ [pbx_config]

To get around this for now - create a 24/7 timegroup and assign that to your outbound routes.

Where is the bug tracker these days and will do a report?

Running FreePBX here


There is already a bug on this but the link to the tracker is “Issues” above.

We have not been able to replicate this particular issue at this time.