Version 2.9 – amportal.conf – Advanced Settings – I’m Confused

Some of us have been using FreePBX for a very long time and are very used to going to [i]/etc/amportal.conf[/i] to make certain changes. Others rely on the powers of google to quickly find help on how to do things which means they benefit from our collective wisdom, which all points to instructions that say [i]”Go to /etc/amportal.conf and change XYZ to abc.”[/i] So why is it when you do that on version 2.9 it does not work and how does all that relate to these new [i]Advanced Settings[/i]? Or if you picked up on Advanced Settings, [i]”why won’t it let me change them?”[/i]

Haven’t gotten to 2.9 yet and wondering what I’m talking about? Here’s [url=/news/2011-02-23/2-9-version-upgrade-module-beta-program-status-more][b]FreePBX Version Upgrade Module Information[/b][/url] from last week.

Since I have made at least a dozen or more comments in the forums and tickets on amportal.conf vs. Advanced Settings often related to this confusion, it’s time to try and clarify what is going on. Historically FreePBX had many many Advanced Settings that had to be configured in amportal.conf. For many users this meant going out of their comfort zone requiring command line access and editors like [i]nano[/i] or [i]vim[/i] or sometimes worse, it would involve blindly following some instructions that turned up on google telling them to run some cryptic [i]sed[/i] command that did some magic resulting in their desired behavior. The problem with all of this was two fold. It’s very error prone and it’s hard and potentially dangerous to do for most users.

Some of the more common settings that you may have heard of include :

[list] [*][b]AMPMGRUSER[/b] & [b]AMPMGRPASS[/b] – sets the default AMI user/password that FreePBX requires and must also be changed in manager.conf
[*][b]AMPEXTENSIONS[/b] – set to either [i]extensions[/i] or [i]deviceanduser[/i] to control whether in Extension or Device and User mode
[*][b]USEDEVSTATE[/b] – whether or not to take advantage of DEVICE_STATE() and generate lots of hints for several feature codes to be used with BLF buttons on phones
[/list] and many many many more… So, what changed in 2.9? Why did it change? Why is there still an amportal.conf file? And other questions…

[b]Why did it change?[/b]

The biggest reason for the change was to make things easier for you, the end user, to be aware of the available settings and help control and police the settings so as to try and catch errors, avoid typos and in general present them inside of a GUI consistent with the rest of your configuration experience. The new Advanced Settings page and framework also forces us to document the settings so that you can get some idea what they do and whether or not you should use or change them.

[b]Why is there still an amportal.conf file?[/b]

The amportal.conf file had three main purposes prior to version 2.9:

[list] [*] It provided the “bootstrap” information that FreePBX used to get started, e.g. AMPDBNAME, AMPDBUSER, AMPDBPASS, AMPDBHOST and AMPDBENGINE (and optionally datasource).
[*] it provided a place to define many advanced settings that ultimately are made available inside of the FreePBX code base as $amp_conf[‘VARNAME’] [*] As a place for additional settings, it is used by other applications in the FreePBX eco system (example, Flash Operator Panel) and probably others that we have no awareness of.

When migrating to version 2.9, we have defined a new and very minimalistic configuration file which is typically located in /etc/freepbx.conf and which provides the bare essentials that are needed to [i]bootstrap[/i] FreePBX now. We’ll talk about all the bootstrap changes at some other time but for now, if you are wondering why the above mentioned configuration variable can not be found on the Advanced Settings page, it’s because they are in [i]freepbx.conf[/i].

The remaining settings have been migrated to the internal database and should all be available from the GUI page.

So if they’ve all been migrated, how come there’s still an /etc/amortal.conf file on your system? Well the third bullet point, those third part applications, is the main reason we still have an amportal.conf. It works as follows, once you have [i]fully migrated[/i], we will start auto-generating an amportal.conf file every time you press the [i]Apply Configuration Changes[/i] bar and all the other configuration files are generated. This makes sure that those third party applications, AGI scripts, etc. continue to have the file they are used to having with all of the updated configuration settings. We expect those applications to migrate but understand that it will not happen overnight. This is simply our continued attempt to do everything reasonable within our power to help maintain compatibility while at the same time improving and evolving.

We do use [i]amportal.conf[/i] in one other place. On initial install, with the use of [i]install_amp[/i] that you may be doing or your distro may be doing for you. The install_amp script will use the specified settings when you first install, to get you started and even to make [i]freepbx.conf[/i] for you if not present.

[b]What does [i]fully migrated[/i] mean and/or Why can’t you edit your settings?[/b]

The migration process for systems being upgrade is a bit tricky this time around. The amortal.conf file has never belonged to the [i]asterisk[/i] user which is usually the same as the apache user; it has typically belonged to root. As such, we don’t always have the control necessary to make changes to amportal.conf when upgrading through the GUI since the permissions are limited to the web user permissions and thus they can’t usually write to amportal.conf. This presents a dilemma because if we can’t write to amportal.conf then it means we can’t update it with new settings if you go and change those settings. So what do we do and how does it effect you?

The simple answer is, until we can obtain write access to the amportal.conf file, we will not let you change anything on the Advanced Settings page. We’ll also try hard to let you know of the issue including Notifications sent to the panel and log messages. Inside of FreePBX we continue to operate much like we always did. This means we will read amportal.conf and update the internal database with any changes that may have been made to that file so we are always consistent. This means you are running in a [i]crippled mode[/i] and thus you are not [i]fully migrated.[/i]

To finish off the migration process, we need to get the permissions changed on the /etc/amportal.conf file. For some of you, it may be no big deal, you’ll just go and make the file permission or ownership change in Linux and be on your way. For the most though, this is again outside of your comfort zone. That’s where another command comes in that many may be familiar with, the [i]amportal[/i] command. (Which is actually the [i]freepbx_engine[/i] command but most people don’t realize that). This is the command that is used to start and stop Asterisk amongst many other things, and it is almost always used (and should be used) by most distros to start Asterisk when you first boot up. As luck has it, this command must be run by root and when you boot your system it is run by root. This means that eventually, and maybe mysteriously, that file permission issue will go away and your migration will be finished and suddenly you will have access to Advanced Settings again.

Of course one challenge here is three fold. FreePBX easily upgrades without requiring either Asterisk or Linux to be rebooted. Linux is rock solid (not like some other operating systems many of us know about) and thus often has up times in months if not years, and Asterisk has come a long way, meaning it often has uptimes in months at least. Furthermore, if you type [i]core restart now[/i] from within Asterisk, it will not run [i]amportal[/i]. Therefore, if you want to get a jump on things, from the Linux Command line, you can type [i]amportal chown[/i] or any other valid amportal comand because each time run, it will check on this permission issue and should rectify the problem for you.

[b]There are settings I want to change but there’s no option to change them?[/b]

There are a lot of very volatile settings available and as a further step to try to protect user’s against fatal and costly errors we have made many of the more volatile settings [i]read only[/i] which means you need to take extra measures to change them. I’ll cover this by describing the 4 available options at the top of the Advanced Settings page, the [i]Advanced Settings Details[/i] category.

[b][i]Display Friendly Name[/i][/b]

We have [i]tried[/i] to use less cryptic names for the settings vs. the internal variable names that many of us may have gotten used to over the years. You can still see what these map to along with a lot of other useful information by hovering over the label and having a look at the tool tip. If you prefer to simply have all the cryptic names listed (which can be very useful for a developer) you can set this value to false.

[b][i]Display Hidden Settings[/i][/b]

This will not be of interest to most people. FreePBX has a number of settings that it uses internally and are never meant to be set or changed by the user. If you want to see what these are, you can change this value to true. You will not be given an opportunity to edit these regardless of the other settings. Only a FreePBX module can do this.

[b][i]Display Readonly Settings[/i][/b]

As mentioned, there are many settings that are quite volatile and by default we don’t even show these settings. If you want them displayed you can set this to true. You will not be able to edit them without changing the value of the last option.

[b][i]Override Readonly Settings[/i][/b]

This is the [i]dangerous[/i] one. When set to true, it ignores the status of all the read only settings and allows you to change them. You should be [b]VERY[/b] careful when doing this because many of these settings could cripple or crash your system requiring some pretty advanced knowledge to get it back working.

[b]Where’s the Submit button, I only have a Refresh Page button?[/b]

Unlike most FreePBX pages, there is no Submit button. Each setting is changed by clicking on the little green checkbox to the right of the setting that will appear when you make a change. Each setting must be individually changed if you change more than a single setting. If these are not coming up for you, assuming you are [i]fully migrated[/i] then check your bowser. We are currently aware of an IE8 issue which is not fixed at the time of this writing. If there are other issues, seek help in the forums and/or once you are pretty sure it’s a bug, file a report in the tracker and please provide lots of details such as browsers and other so we can reproduce the problem.

So there you have it! In addition to the roughly 100 or settings that existed prior to version 2.9, you can now see the MANY settings available since then (at last check, somewhere close to 200 in all).

[b]Philippe[/b] – On behalf of the FreePBX Team!

2.9 Version Upgrade Module, Beta Program Status, More

The beta program is progressing very nicely and we are getting some really great feedback from a handful of people. I suspect the rest of you are out there silently testing and finding 2.9 flawless and feel we should just make it final! Well that’s probably wishful thinking on my part so my request is, if you are testing and have general feedback, please speak up. You can comment on this blog and let us know it’s going great, it’s not, etc. It always helps to know what aspects of the system are being tested and an idea of how many people are really actively using it.

[b]Installing the Upgrade Module[/b]

My general sense is that it is going good but not quite ready for a release candidate, though not too far off. The one gating element that usually ramps up beta testers like a hockey stick is when we publish the [url=]2.9 Version Upgrade Tool[/url] to the online repository so that it just pops when people check for online modules. Well we are often tempted to do this since we provide [b]lots[/b] of warnings before you can actually commit to the upgrade, but we try to air on the side of caution. Most of you have learned to blindly trust anything we throw at the online repository and for that we are flattered. Therefore, we want to be careful not to introduce any surprises on you!

For now, there are a couple steps involved but it is still very straight forward and you can still do it all through the GUI.

Here’s how you get and install the Upgrade Module:

[list] [*] Download the module to your desktop: [url=]2.9 Upgrade Module[/url] [*] Make sure 2.8 is fully up to date from all 2.8 available Updates.
[*] Click “Upload module” in Module Admin
[*] Choose the file you just downloaded (versionupgrade-2.8.latest.tgz)
[*] Click Upload
[*] Go to Manage local modules
[*] Install the new module (should show locally available)

At this point you have done the equivalent of downloading and installing the module as if it had been available online. The rest is the same as it always has been:

[list] [*] Go to the ‘2.9 Upgrade Tool’ tab
[*] Choose to upgrade and confirm
[*] Now check for Online Modules again, and you should see the Framework Module, load that
[*] Next, load Core
[*] Now load evertyhing
[*] Done! – start testing and exploring away!

For those of you who have been through this before, we’ve made some minor but very helpful improvements. As you step through the upgrade process checking for modules, [b]only[/b] those that you should upgrade next are displayed in Module Admin. This is important since it is often required to follow the order specified in the upgrade process or [i]bad[/i] things can happen. This keeps you from going astray. The entire process should take no longer than a few minutes with a good internet connection. We’ll continue to monitor the feedback and when we are comfortable, we’ll move the module online thus “opening the flood gates” on the next step of testing.

[b]General Beta Status[/b]

Overall the program is progressing very nicely. We’ve seen the normal inflow of tickets and have been fixing them quicker then they are coming in. The tickets have been a mix of new 2.9 changes and existing issues that often get reported during beta programs but are not unique to the new release. There was a good chunk of work put into the new Asterisk 1.8 Call Camp-On feature and associated module that I added. We’re trying hard to make sure this gets accepted into Asterisk 1.10 at a minimum and your feedback and testing on the Device State Camp-On patch would be invaluable to make sure the Asterisk team sees enough interest and testing to make this happen. It’s also up on the Asterisk Code Review boad so [b]please[/b] show your interest by commenting on the ticket so that we get this in! Other Asterisk related patches that will help with 1.8 themes we’ve tried to pursue and you may be interested include CallCompletionRequest/Cancel fix and a Call Parking Connected Line fix both of which should find their way into 1.8 as bug fixes but your interest in seeing these happen (and thus your testing) will go a long way to raising their awareness. One last one that we currently have a bit of a kludge to work around is Asterisk Bug 18772 which is currently in need of someone smarter than me to come up with a patch to fix it (the others I was able to struggle through and supply patches in hope that they would accelerate fixes and adoption).

Given the current bug rate and feedback, my best guess for future release dates is another week or two in beta before I feel comfortable going to a release candidate, and once there, it’s usually another week or two for final, so we should have a final release before the end of March which keeps us within tolerance of the planned release date.

[b]Other News[/b]

I’ve talked about doing a project phone conference and although the feedback has been minimal, it’s still in progress. SkykingOH has come up with a phone bridge on top of “unlimited” bandwidth so I’ll be testing with him shortly to make sure all looks good and then pick and announce a date! I’ve hinted at the fact that Moshe (mbrevda with has been working on some really cool stuff in the background, and I’m here to simply tease you and say that it’s still coming along nicely but we aren’t ready to surprise you quite yet! Lastly, we get regular inquiries about the [url=]next OTTS class[/url] as it has been a while since we put one on. We’ve had a few false starts on logistics and locations but stay tuned as we hope to finalize something within the next couple weeks for the next class, and will make sure to include LOTS of 2.9 content in it. We are also looking at adding a one day class to focus solely on ACD (Queues) so for those of you who have a strong interest on that subject including past OTTS graduates. stay tuned!

For now, I’ll let you go so you can go pull down that [url=]2.9 Upgrade Module[/url] and get testing!

[b]Philippe[/b] – On behalf of the FreePBX Team

Bugs, Feature Requests and the Ticket System

This is my second blog here on FreePBX, [url=]the first one[/url] was in 2008, that blog covered the localization system in FreePBX and the struggle we had to make FreePBX working in different languages.
A lot of thing have happened during these past years. We have gone from FreePBX 2.5 to the upcoming FreePBX 2.9 and it has been fun and educational.

But what do we actually do as a [b]Developer[/b] in FreePBX? The question arise from time to time and I decided to write something about what we do and how we do it.

First of all we fix bugs, that is the main priority. Then, between FreePBX releases, we add features to FreePBX.

[size=15]What is a Bug, and what is a Feature Request?[/size]

A [b]Bug[/b] is when something is broken in FreePBX.
By broken we mean that something does not work when you call into the system (or call out) due to some error in the Asterisk dial plan. Most bugs are detected in the alpha or beta release.

Then there is the [b]Feature Request[/b], that is when someone wants to have a feature in FreePBX that he or she find useful.
This is something that extends the functions and features in FreePBX. A feature request can be for inclusion of more fields in Extensions, like new peer settings when using Asterisk 1.8

[size=15]Someone posted a Bug that was changed to a Feature Request, who decided that and why?[/size]

The decision is made by the developer that first read the ticket, he first try to duplicate the bug, if the ticket is found valid and the Developer can duplicate it, it stays as a bug. When the ticket is examined it is also checked if the posted details in the ticket can be valid as a bug. Sometimes the ticket is changed to a Feature Request, the poster want to have a function in FreePBX that extends the current implementation.
A ticket change it’s not a matter of ‘right or wrong’ as both the reporter and the developer may be correct from their perspective. For the project, the developer base the ticket change from the amount of work to address the desired change which may involve incremental development and/or testing of various scenarios vs. ‘fixing’ some ‘broken’ scenario.
[u][b]A ticket change should never ever be taken personally[/b][/u], we base ticket changes from the reported issue, not by the reporter.

As a reporter, someone may run into an issue that they consider major or even critical for what they are trying to achieve. As a project, we will try to assess the relative priority based on both existing bugs as well as our judgment as to the impact on the project and user base as a whole. None of these changes should ever be taken personally and we are also very capable of making mistakes whether in such changes, or even closing bugs for any reason. You are always welcome to ask why something was changed or respectfully disagree providing your reasons why you think something should be different. We have made plenty of mistakes in the past as does everyone and making changes once things are civilly discussed is very easy for all parties involved…

[size=15]Do I get payed to work as a Developer for FreePBX?[/size]

No, I don’t, I do this mostly on my spare time. The company in Sweden were I work have been using Asterisk and FreePBX for about 4,5 year now.
It is a busy system with a lot of queues and ring groups. We currently have 5 locations, 90 SIP phones, 326 DID’s and one server. We use SIP all the way.
Most of the bugs in FreePBX that I have found was from using FreePBX at work. Ticket 3963 was discovered when I added a new extension and our support department came and asked if there was something wrong with the PBX as they have not received any calls since an hour and a half. The time spent on fixing that was donated by my company.
A ticket that I looked into was #3805, I helped out by adding extra detection for certain HANGUPCAUSE, timboothby filed the ticket and nicson provided some details and code that I could use, Philippe have provided a new module, Route Congestion Messages, that we added the code to.
We needed this at work as we use Grandstream phones, and they have a default timeout of 4 second before the phone automatically dials the number, but sometimes a person begin to dial a number, pauses for some reason, and they get “All circuits are busy now”. With the addition of HANGUPCAUSE 28 I could record a message that says “The number you have dialed is to short”.
I also have taken under my wings two modules, Bulk DID’s and Bulk Extensions, as I find those two modules quite useful. By doing that, those modules are now in the main repository for FreePBX and are maintained on a regularly basis.

I do hope this blog will let you understand what choices we make regarding tickets and why we decide how to classify them.

From time to time we get appreciation from users that find FreePBX valuable (thank you), sometimes we get bashed for doing things that one or two dislikes.
But we continue our mission, to make FreePBX the best GUI for Asterisk.

Mikael Carlsson

2.9.0 Beta1 Now Available for Testing

After knocking out what seemed like a couple dozens bugs and feature requests over the weekend we now feel comfortable moving 2.9 into a Beta 1 release! We are really excited with what is shaping up with the 2.9 release and are looking forward to increased testing and participation now that we are over the Alpha to Beta hump! We look forward to your active participation to get us toward the next hump towards a release candidate!

[b]Beta 1 Plans[/b]

Here’s a quick lay of the land for what should be coming down the pipe. First off, there is a small handful of features that should be tied up and pushed out with module updates over the course of this week. Included in those is the Call Confirmation option for queues and the inclusion of some existing parking options not currently configured. Throughout the beta1 phase we’ll continue to look through other open tickets in the [url=/trac/milestone/2.9]2.9 Milestone[/url] to see if some of the other pending feature requests might not get in, and of course we’ll have a closer look at the different bugs that are reported to address as appropriate.

I’ve also included the new [url=/news/2011-02-11/call-camp-on-in-2-9-and-i-thought-alpha-was-going-to-go-beta-this-week]Call Camp-On[/url] module that I blogged about last week. Currently the module assume that you have Asterisk 1.8 installed complete with the BLF Enabling Asterisk Patch Issue 18788 which is also up on the Asterisk Code Review board for consideration. We’ll wait to see what sort of feedback we get before making changes in the module to accommodate a ‘crippled’ system that does not have the patch. For now, you will just have reduced functionality. I encourage anyone who thinks it is important that this patch finds it’s way into Asterisk officially to provide feedback against their issue tracker so they are aware of the interest.

To recap how far we have come, as of this writing we have closed [url=/trac/query?status=closed&group=component&milestone=2.9&order=priority]349 Tickets[/url] comprising [url=/trac/query?status=closed&group=type&milestone=2.9&order=priority]224 bugs and 125 Feature Requests, Module Submissions and Patches[/url] and currently there are a total of [url=/trac/query?status=new&status=assigned&status=reopened&group=type&milestone=2.9&order=priority]43 open bugs and 25 feature requests and patches[/url] associated with this milestone. Those tickets that don’t ultimately get closed during this Milestone will automatically role forward to 2.10.

In order to help accelerate testing, we’ll also work on getting a downloadable upgrade module that can be used to bump from 2.8 to 2.9 and try to have that out some time this week if you are not comfortable upgrading with the [url=]2.9.0 Beta1 tarball[/url].

[b]Community Phone Conference[/b]

With the move towards Beta and new feature work slowing down along with more thought starting to go toward 2.10, I want to drive forward arranging the phone conference I suggested last blog and previously. I have not gotten much feedback as to general interest in joining a conference though that may be that I posted just prior to the weekend. Please speak up so we can get an idea on potential participation and I’ll get back within a few days with a suggested date.

For now, thanks for hopping on board and helping with the Beta testing and we hope you like all the new features that have found their way into 2.9!

[b]Philippe[/b] – On behalf of the FreePBX Team!

Call Camp-On in 2.9 and “I Thought Alpha was going to go Beta this week”

I said that I would move the current 2.9 alpha to beta stage “later this week” and here we already slipping the schedule… No, I was not off getting my last fix on My Favorite Sail Boat before she finds a new home, though that would not have been a bad idea 🙂 I’ve been busy cranking on some of the Asterisk 1.8 features that we’ve discussed, more on that…

As I’ve mentioned in past blogs, there are a lot of really cool features that were introduced in Asterisk 1.8. One of them is the CONNECTEDLINE() function and underlying SIP update abilities that now allow us to deliver reverse CallerID. This means things like a call pickup can show you who the caller was on your CID, or if someone transfers a call on you, you can see who they transferred it to.

The main feature that I’ve been working on is the Call Completion Supplemental Services, or Camp-On. Being a new feature that is quite sophisticated in nature, I naturally ran into a handful of bugs or short comings. Mark Michelson has been a great help adding in a few bits and pieces where there were minor short comings in the implementation. I have hit a couple bugs (Asterisk 18763 and Asterisk 18772) that have an impact on the FreePBX implementation. One of them I provided a fix for, the other one requires a temporary work-around kludge that I have added to FreePBX for now until it can get resolved.

My big distraction, but in a good way, has been to implement Device States for Camp-On. I wouldn’t exactly call the lack of this a bug in the feature, but it is clearly a ‘huge missing piece’ that would otherwise make this feature code join the long list of cryptic features that no one uses because unless there is a button on the phone, with good feedback, it won’t be used.

So what am I talking about wrt to all this Device State stuff? Well the CCSS team who implemented this feature did so with a lot of foresight and for that I commend them! They designed the feature to work in conjunction with native technology abilities so as to maximize the usage and flexibility of CCSS. What does this mean? It means, if your phone supports the Camp-On feature and the channel driver has been modified to handle it natively, then you can reap the benefit of CCSS in conjunction with native phone capabilities! This usually translates into very usable features with dedicated buttons on the phones, subscriptions by the phones to be updated about availability or to update the CCSS core about their availability, etc. The good news is at this time both SIP and ISDN channels support native CCSS implementations. The bad news is that I’m not aware of any SIP phones that actually support it:(

Knowing that we can’t count on technology specific capabilities the team also created a generic agent and monitor type. An agent is the person trying to make a call and camping on the ‘victim’ where as the monitor is the ‘victim’ who we are stalking! The implementation takes advantage of the great Device State subsystem that Asterisk has, watching the various states of monitors and when they come available, informing agents if they themselves have not become busy. This works great from the testing that I’ve done! It’s also possible, at the CLI, to see what state various agents are in since all of this is implemented with an internal state machine in Asterisk.

Now all of this works great but as I mentioned, there is no feedback today. I can camp on to an extension that I am trying to reach, but we can’t provide any feedback on the phone showing that there is an active callback pending. That also means we can’t provide a single button that would let you camp onto the last call made, and with the same button, cancel that callback request. What we would like to do is the following. Upon making a call and not reaching our party (or their line ringing busy), press a single button to request a callback from them. Once done, the light on the button lights up. This gives us a visual indication and reminder that we are currently waiting on a callback. If we decide to cancel the callback, we can simply press the same button and a cancellation is put through, turning off the light. Taking this a step further, while we are waiting on a request, we happen to be talking to someone else when our party becomes available. Our Call Camping light now begins to blink rapidly, giving us a visual indication that our party has become available, since we might want to take the opportunity to end the current call so we can get connected to our otherwise hard to reach victim! Similarly, even if we are not on the phone, our light rapidly blinks in conjunction with the call completion callback that rings our phone so that we can connect with our party.

As you can see from this description, we have taken a great phone feature and made it extremely usable in the above scenarios. I’ve implemented this capability in Asterisk with the addition of DEVICE_STATE information to CCSS such that with this patch, generic devices can now have a BLF enabled button that allows them to toggle camp-on requests on and off for the last call made, show visual feedback that a request is pending, show visual feedback that a callback is now possible if you are on the phone, as well as visual feedback when receiving a call back that the incoming call is a callback! Do you think that this capability is important for a proper implementation of call camping? If so, please help test out this patch and post feedback on the ticket. If you are a developer, your feedback on the Code Review board would also be great. I’d like to make sure at a minimum this gets introduced into Asterisk 1.10. To the extent that one could make an argument that this is really ‘lacking’ in the current implementation and could be considered a border line ‘bug’ then maybe one could make the argument to actually get it introduced into the 1.8 branch as a ‘bug fix.’ (And just to be clear, from what I have so far tested, I think the developers of this did a great job implementing this, and this is simply the Open Source process taking a good thing and making it great!)

Ok … enough of that, a couple book keeping items. I’ll try to get the move from alpha to beta this weekend so as to get caught up. Another thing I want to get back to is the Community conference call that I mentioned a few blogs back. In order to get a feel for what size bridge we may need, any of you reading this who would definitely plan on joining the call, please reply to this thread so I can try to be prepared for the onslaught. Then I’ll try to schedule and work out the logistics soon.

Philippe – on behalf of the FreePBX Team!