Search results

thanks - checked the horizon page and saw it was running. Set a new schedule and working now. Must have been the caching thing that cleared.

cool - late evening here, will test in the morning and report back

Hi I have set up a test scheduled announcement but either I am doing something wrong or it's not working Set the time for a few minutes from now, created a recording and set my test extension, but no call is received and under "runs" I see 0 so it does not look like it has tried to run this...

I am reading the reply again and only now see that you can also set a condition under domain variables - so @ja133 that means that this may indeed be possible. Thanks for that input!

@ja133 the issue is not so much that - the problem is that the call goes out through an outbound route, and because we have a domain variable set that add a PIN code request before the call goes out to the gateway, any outbound route for that domain is subjected to this. I am trying to see if...

A number of our customers use PIN codes. We use a few global outbound routes. The easiest way to add pin codes is to simply add pin_number.lua in the domain variables. This works fine - except when someone has a call forward set to an external number as it will need a PIN code to dial out. We...

great, waiting (im)patiently ;)

Now that we have a kick-ass customer interface we have to deal with customers messing things up. Because they invariably do, no matter how easy we make it for them. We have a had a few case where things stopped working and upon checking could see that routing must have been changed. We then get...

perfect, super impressed with the speed at which nigglies get resolved (and with the speed of development in general)

We have set limits for the max number extensions allowed on a domain. When this is at the max - so say limit is 10, and the domain has 10 extensions, bulk edit does not work. It throws an error "sorry you have reached the max number of extensions allowed" - but we're not adding another one, we...

Yes I know, those are the suggestions to people, but the issue is the same as always "we have always done it like this and that's how we want it, I just want to press "transfer 150" and put the phone down and forget about it. Change is hard for people

Something that comes up all the time, and to my knowledge is not possible without some voodoo dial plan, is that customers expect that when a call is transferred, and not answered, it goes back to the extension that transferred the call. This is how traditional PABX systems typically worked. As...

Answering my own query (waking up after a long weekend). The easiest would just be to NOT set a diversion header for the internal calls that are forwarded - will have a look at how to achieve that but that should be doable I'm sure.

For a call forward we have to use a diversion header in our regulatory environment. The diversion header will stipulate the originally dialled number. We have this working fine, except when it's an internal call. When Extension 100 dials 101, and 101 has a call forward set, it will put 101 in...

Before the rewrite of the page, the last action would show bridge > and has a the gateway NAME. Once you click on it, it will show the UUID. This made it easy to see which gateway is specified there. On the new page, it has the UUID there with no reference to the name of the gateway. This...

https://github.com/nemerald-voip/fspbx/releases

Fax? what is a fax? ;) ;)

Hi FSPBX started as a fork of FusionPBX which is also stated clearly on their website. There are definitely remnants of FusionPBX but pages are being reworked fairly quickly at the moment. The most important pages, and certainly the customer facing ones, have been redesigned. The ones left, to...

This is actually something many of our customers get wrong because the "add members" is hidden by the box. So they click Save instead. Despite us mentioning it in our little write-up for customer (who never read it anyway). I think there is room for improvement by not obscuring the "add members"...

we'd consider that at a later stage. Currently we're really busy moving people over which is a job and a half, but so far proving worth it.