FreePBX 2.10 plans - what we are thinking

Blog Commentary
1

WIth 2.9 solidly behind us and one of the most feature rich releases ever, we are really pumped to keep up the momentum and brining you more great things! Several of [i]us[/i] (active developers) spent some time last week to map out what we want to try and accomplish in the next release, when it should come out, and tackle the hard problem of what we will need to move out of the 2.10 wish list so that we can get a release out before the end of 2012! Since it's really important for us to bounce off such plans on all of you, I wanted to share a summary of what is on our mind.

Because the last release cycle was just shy of a year and incorporated some substantial architectural changes, we thought we would take a bit of a breather and shoot for a target date of Astricon 2011 for our next cycle, which means right around Nov 1. Since 2.9 has been out for about a month, this means we have about a 6 month cycle, or 5 months from now. That will gauge what we can and can't get in.

So what are we planning in that time frame? I will be updating the 2.10 Milestone to reflect more details of our current thoughts, but in a nutshell this is what we have in mind. First, what are the big things going into the release that people have currently signed up for:

[list]
[] Call Recording functionality. This is the one “big ticket item” that we want to try and tackle in this next release. For those long timers who care about call recording, you are probably aware of the limitations and issues with getting calls recorded. Our plan is to revisit the call recordings ability system wide and try to come up with an overall call recording capability that deals with policy constraints such as call recording between extensions if one allows and one doesn’t, etc. More to come on what we have in mind once we sit down and really start to design this out.
[] Backup Module. Schmooze has stepped up to the plate and is planning on doing a rewrite of this module that has been long plagued with various challenges. Although this module often works fine for many, there continues to be a background ‘buzz’ of various issues that continue to be encountered and no one likes to find out that their backups failed at the time of restoring. Add your thoughts/comments/feature requests to this thread!
[] IVR Module. Schmooze has also stepped up to the plate with a plan to rewrite this module. Details of what this means for features will be forth coming, but many of the changes are more internal coding changes that will facilitate our ability for other modules to “hook” into this. (This allows new functionality to be introduced, for example, a speech recognition module that could add the ability to speech enable an IVR).
[] New Features. This is always the one we have a lot of fun with and where we can best engage the community! We have yet to dig through the hundreds of tickets or hear your feedback to blogs like this one in determining what we can squeeze into this release so that will all be forth coming. There are lots of ideas and I’m sure plenty of you will take this opportunity to add more! We will do our best to listen to all the input, read through all the tickets, and see what we can realistically get into the release given the time schedule and other “big” changes we are working towards! For now though, feel free to toss out your ideas!
[/list]

Outside of these major points, there are other decisions we have made going forward. Here is a summary and there will be more to come on some of these.

[list]
[] Asterisk release support: This topic is always sensitive and there has been a lot of discussion about this for quite some time. The challenge we always face is how far back to support an Asterisk release, in conjunction with their own support life commitments, and at the same time try to innovate and come out with new features and capabilities. In the timeframe of this release, 1.8 will have been out for a year and its stability is anticipated to be quite solid (it’s already looking pretty good now). Asterisk 1.10 will be coming out at the same time and as always we want to support the newest release. Both 1.4 and 1.6.x have already had their end of life announced and by the time 2.10 is really mature, will no longer be supported by the Asterisk team. Given all that, we’ve decided to take the approach for 2.10 that we will focus on 1.8 and 1.10 support. This does NOT mean that it will not support 1.4 and 1.6, it means that we won’t go out of our way to support those and it’s unknown until we get a bit further down the road if there will be support issues for these releases. We will evaluate the situation further down the road and if it turns out that these release will be affected, we will make sure that 2.9 has a long enough support life to cover the requirements of those in the community who need to stay on older Asterisk releases, even to the extent that the Asterisk team is no longer supporting these.
[] PHP Support: We will no longer support PHP4, which should not be an issue as PHP4 has been obsoleted now for multiple years and the measurable FreePBX population still on PHP4 is almost insignificant. We will be coding against PHP 5.3 and even though current releases of popular Linux distributions are not yet on 5.3, FreePBX already comes with a compatibility library that includes the missing pieces such that these will all be fine.
[] A few things we will be deferring because of the release schedule is a rewrite of the User Portal (ARI) and the replacement of the current CDR Reports. However, due to the Call Recordings re-architecting mentioned above, the ARI will be maintained so as to tie into those changes.
[] FOP: This one is a challenge we have been wrestling with for quite some time. The current FOP is not being maintained given the FOP2 that asternic has had out for quite some time. FOP2 is an excellent product and will be available in our Market Place, but the free version is quite lacking in its inability to have any control as to what gets displayed in the 15 free icons, thus making it very difficult to evaluate if it’s worth the purchase. (For you big sites, that’s not really an issue, but for all the small guys and hobbyists out there, it matters a bit more.) However, as it stands FOP does not really work and is plagued with issues which are not being addressed and we feel our hands are a bit forced in that it probably needs to be removed. That means outside of FOP2 (free and commercial) and the iSymphony solutions that will also be available in the marketplace, we are left without a good “free” replacement for FOP. We are happy to hear your thoughts and ideas around this as we really feel it’s something that is not in our control.
[/list]

Well, there’s a pretty good overview of what is going on and where our collective thoughts are at. We really look forward to hearing from you as we continue to move forward on this and will make sure to keep you up to date and incorporate your feedback into our planning process!

Philippe - On behalf of the FreePBX Team!

2

The “2.10 milestone” link should be: http://www.freepbx.org/trac/milestone/2.10

(feel free to delete this comment after updating)

[update: fixed. Thankx! --mbrevda]

3

thanks peter, forgot to check the links :frowning:

and thanks mbrevda for fixing that!

Now I just need to go update it so it doesn’t contradict what is written here…

In the meantime, we welcome comments and discussion on the above, we value your input!

4

We spend a lot of time in the CDR for situation diagnosis. I customize the asterisk-stat-v2 to suit the needs of each of our groups. I’m actually curious if others use it, don’t use it, or use it a lot like we do. We just don’t use it as part of the FPBX distro.

Could there be an option to enable the recording of each call from the beginning of the call and then only save the call if the user requests prior to terminating the call? Suppose they do *1 at the beginning of the call or at the very end. The call would be recorded in it’s completion either way. (Other vendor’s schemes come to mind, but just keeping the whole call makes the most sense to me.)

We have many users who will call into a conference or many external calls into the a conference. Each of these channels end up recording the same call. It seems like a small issue with just a handful of callers, but when there are 60+ in a single conference it seems odd to record each uniquely. If there were a way for the logic to only record one copy starting when the first caller enters a meetme and the rest of the caller’s CDR link back to the same file?

I don’t know how common this would be, but it would be nice to be able to email some calls immediately after the call much like what happens with voicemail. At that point it could delete the file too.

Lastly, more an issue of bundling asterisk in a distro, including the option to transcode voicemail and call recordings into mp3 files without having to massage the system would be nice.

FOP has been useless for us. If it went away altogether we’d not notice.

5

Peter,

on the call recording suggestions there are some good ideas and as soon as we strike up a separate thread (or likely a page on the trac wiki) we will start to consolidate some of that.

Things like the Conference rooms with each channel also being recorded is a great observation that would be nice to avoid replicating.

The on demand recording saving the whole conversation is probably possible with some application feature codes that we could investigate. The downside is it implies that we would actually record every call and then disregard the recording if they didn’t ask for it and that would put quite a load on the system. However, the feature is a great idea and on a system that can handle all that recording, would be valuable to some. I guess another angle on this which we should think about is how we could design the system such that external call recording packages could be used and tied into the same controls/permissions/etc. that we are designing in…

6

I like a lot of Peter’s ideas there, to build on that, CDRs reallllly need help, I think it is terrible that you cannot track a call from end to end - for instance you can see channel info, but if it came in on a SIP trunk that has more than 1 DID, you cannot see the DID, this is something basic that should be logged. The CDRs give a lot of info, but at the same time are still lacking a lot.

To build even more - it would be nice to have a tick box in the IVR section that says “Log this selection to the CDR”, so if someone presses 1 on the IVR, it gets logged on the CDR.

7

totalimpact,

concerning the CDR fields, we do plan on adding additional fields where possible since one of the benefits of 1.8 (and I believe it was introduced in 1.6) is to have additional arbitrary CDR fields.

So DIDs is one example of what we will look at adding. This does not “fix” many of the fundamental problems of CDRs but it does help improve what is already there. There will also probably be limited modifications to the CDR reports page, though something like DID fields is probably something we would want to try to expose.

As far as your IVR type requests, this is something more suited for CEL and something that is very much of interest but is unlikely to make it into 2.10. That doesn’t mean we can’t start putting in some CEL logging features already but there won’t be any infrastructure to set it up or run reports on though an interested user could obviously do that manually in Asterisk. One of the things we had in mind wrt to CEL was to add “user level” logging at every step such as when running through a call flow module by module, and adding extra info such as IVR selections as a CEL event, assuming it is something that can be done. (And I suggest with such specific ideas that you file trac tickets so when we eventually work on this the ideas don’t get overlooked.)

8

I’ve been doing this for a few years.

(We don’t otherwise use accountcode.)

[from-pstn-custom] exten => _+1.,1,Set(DID=${EXTEN:2}) ; Remove +1 from DID exten => _+1.,n,Set(CALLERID(num)=${CALLERID(num):2}) ; Remove +1 from CID exten => _+1.,n,Set(CDR(accountcode)=${DID}) exten => _+1.,n,Goto(from-trunk,${DID},1) ; Go to from-trunk exten => _X.,1,Set(CDR(accountcode)=${EXTEN})

(Looking at the code above, slapped together years ago now, that might stand for a little fixing.)

I don’t suppose there’s a way to hook via the ivr-*-custom to track the key events because it uses WaitExten. If there were, the progression of what the caller did could be trapped in a channel variable by appending each event. (just thinking out loud)

9

Peter,

The new CEL system is exactly made for such event tracking. Given that, it’s the way to go imho.

As mentioned, it’s “easy” to add dialplan to start to track such events which we are not adverse to doing. It means those who need this can manually setup CEL logging and do their own analysis until we can get something integrated into FreePBX.

Maybe some motivated developer will go as far as to consider creating a module (free, commercial or both) that can accelerate this. We do have the commercial market place now so …

10

If possible, I would like to have the ability to define a preferred outgoing route for each extension.

I know this is possible with some creative use of prefixes or “Custom Contexts” but I would feel more confident using it if it was simply an option during extension creation.

I had previously used “Asterisk GUI” in which you created “DialPlans” (I guess this was it’s own custom context) which consisted of an assortment of “Outgoing Rules”, each extension was then tied to a “DialPlan”.

Our company has 3 internal departments and this not only helped to track each departments usage but also made sure that the outgoing CID was consistent each time. As a side benefit it provided a very simple way of controlling who could make International calls etc.

11

there are multiple ways to achieve what you are asking for.

You can use the “unsupported” custom context module to do this, which is in fairly wide spread use so there is a large base for community support on this.

You can also use the CID field in the outbound routes to restrict routes to certain extensions.

Both of these options, although possibly slightly tedious, are fairly straight forward to implement.

Not to say we are not constantly looking for ways to make things more intuitive but just fyi in this case…

12

Just that “unsupported” word makes me nervous I guess =)

Thanks for the reply

Regards

John

13

I, for one, will miss FOP. I don’t use it for call handling (transfers, etc), since it sucks at that. But it worked fine, at least most of the time, for just being able to see who was on the phone and which line they were using, and which incoming line/trunk was ringing on inbound calls. Simple troubleshooting and system status while doing MACs to the system.

Something that performs that functionality within FreePBX would be awesome. Even if it’s a text only table-like layout with several columns which stay updated with relevant information: Inbound/Outbound - Call destination/origination (extension/IVR/call group in use for the call) - Number calling/called - time of call - trunk/line - etc

Or, could FOP just be re-written/simplified to be read-only (no call handling)?

Or is there something else I could use?

14

I agree with the previous poster that FOP is very handy to get a quick overview of extension and trunk status, view active channels and calls, etc…
So please leave it in for the time being until a good alternative is ready to replace it.

15

Some of the issues with FOP:
[list]
[] it sucks a TON of system resources (we’ve seen major system performance degration, especially when using queues)
[] It also is a pain to configure if your not using the default layout (say - if you have more extensions that fit on the page)
[] most of the functionality is outdated (i.e. doesnt work with asterisk 1.8
[] is poorly integrated to FreePBX and has no developer standing behind it
[*] is no longer maintained, even outside the realm of FreePBX
[/list]

From a non this-is-cool-to-show-off-when-it-works point of view, I really think it needs to go. As they say: “No point in beating a dead horse”

16

@TechOne - no, fop cant be easily rewritten (otherwise we would have!). Yes there are other products on the market that dont suffer from the downsides that fop has. Have at look at iSymphony for one.

17

@orion - the question is if the end justify the means. Even its limited use is limited, meaning that even those installs that can use it just to see which extensions are in use are limited: There are many factors in play when using fop, and the resources that it consumes (both from your system and from a development point of view) really doesn’t justify its continued inclusion.

By way of clarification, we are by no means against having a properly working, properly maintained product as part of FreePBX. We have been EXTREMELY patient with fop to see if there will be architectural improvements and to see if anyone will step up to the plate to maintain it. We are totally cool with a replacement - provided it meets certain guidelines (mainly, that it doesn’t suffer the same issues that brought us here in the first place). At this point however, it seems that the time has come to pull the plug.

18

Greetings …

Improvements to CDR would be welcome, I did a little hacking to add the PIN codes display and might even be better to be able to display People/Accounts with PINs, but that is a pretty small coding project. What would be nice, is the function to be able to import call costing from Telcos. Giving users the ability to keep the Telcos honest and also a first step at better cost predication and maybe work on Least Cost Routing, using the imported history, just an idea, that I wish to work on during some spare time.

Call Recording, accessible via User Portal or e-mailed after a call, I think somebody has already suggested this, but I can see working and easy to put in place for my users.

FOP is great for diagnostic or to inform users with larger systems or simple phones, but yes, it has many failings, like, not working well with mISDN system. Still need to figure out why the latest mISDN FreePBX module is not working.

Thanks
Mailed
LeeT

19

For those using FOP and Asterisk 1.8, what are you seeing?

What is working, what is not working?

From the bits and pieces of feedback we are getting, we keep hearing it is severely broken in 1.8. Is that really the case? I understand the concern of FOP going away. As I indicated in the post, we feel our hands are tied. We are not “deciding” to take it out. We are feeling that we’ve been “beating a dead horse with a stick” for a while now and the horse just is not coming back to! We’ve also looked at multiple other solutions and have been in constant talks with other vendors such as the guys at iSymphony and asternic wrt to FOP2 to see what might be possible for alternative “free” options which would address the “hobbiest” base that may not be able to justify paying for a solution, while making sure there are high class paid solutions which there are (again, products like iSymphony) with whom we have been working together for years to get these professional solutions more tightly integrated with FreePBX and which will be available in the marketplace.

So feedback on 1.8 please in case we are not hearing right?

20

I can certainly understand why FOP should go away, considering performance problems.

Does iSymphony show trunks/lines? From what I’ve seen of it, it doesn’t. I really want to be able to easily see what inbound trunks are ringing, and who is on the phone with which external caller, etc…