Any news update on the status of 2.6?
According to the 2.6 Milestone page ( http://www.freepbx.org/trac/milestone/2.6 ), it’s “Due in 1 week (03/20/09)”, but there are quite a few open tickets and not such an awful lot being comitted/merged in the 2.6 branches.
Is there a planned date for an alpha/beta or even final release?
(Just asking in order to do my own planning, I don’t want to hurry you, guys!!!)
While I wish thing could be spelled out a bit clearer, the page has been updated as clear as it can currently be.
lazytt: Thanks for the update! I mainly was a bit confused because of the due date on the page…
the roadmap needs some cleanup, I’ve been a bit behind. Clearly the date is off. But we should be putting together a tarball beta in the not too far future and cleaning up what will be coming out on the Milestone.
Since one year, the FreePBX project seems to slow down.
Why ? Is it because it is now a mature project, because of Bandwith.com, because there is not enough money for the developpers, or because the code has become too much complicated to allow for easy upgrade ?
A lot of users are waiting for dial contexts, anounced about one year ago.
What is the futur orientations of the project ?
I 've found that generaly Opensource project users or eventual funders do not have a clear view of the sky.
I think that the blog should give a bit more informations about the true internals of the project, so that everyone can have a clear vision.
Trainings are certainly a good source of informations for peoples who can subscribe, but most users can’t.
Thanks.
I think if you look at the activity in the project you will see that is is VERY MUCH active. The 2.5 release was one of the most intensive releases that had come out in the entire history of the project, all well within the last year that you feel has been slow.
New releases are usually approximately every 6 months give or take a few months of elasticity and given the output from 2.5, 2.6 is on the longer end of the spectrum this time. And in particular, about a month or so behind as I did not want to kick off a formal beta program just before running off on vacation for 3 weeks which I just got back from last week.
So … nothing to worry about, the release will be coming out momentarily preceded by a normal beta program. In addition, we’ll be updating you on plans around 3.0 soon as well since there will be activity on both fronts. I just need to decompress and get all that rum out of my system that 2+ weeks in the Carribbean forced me to absorb:-)
Good news Philippe. Thanks for the input.
Philipe, some news about 2.6 beta and 3.0 versions ? What the actual state of the project ?
2.5 was a very nice cleaning, but not really a bunch of new functions.
I think that a lot of people would like a fully working custom context, this is the most important and most urgent addition.
The interface need to be redesigned as well, with a deeper “Ajax” style programming, to speed up refreshes.
I still feel that the project slow down. Perhaps that the new interface for the FreePBX portal is less attractive than before, slowing down the Forum activity.
Best regards,
Olivier.
I’ve procrastinated on getting the tarball rolled up to make 2.6 more accessible, that’s my bad and will be working on that soon. But it is completely accessible in SVN if you want to get going with it and should be pretty solid.
As far as features, 2.5 probably had more new features then any previous release, so that is a little confusing. The 2.6 will have fewer then 2.5, as there has been some work done in some of the “plumbing” though not as much as I would like, sigh. There are some nice areas, for example queues, that have had some useful things added and if I could get the queue patches into Asterisk that I did on 1.4 and are in their bug tracker, I’ve got all the FreePBX code to take advantage of them sitting in my working directory ready to check-in…
As far as interface redesign, that is the goal of 3.0, along with everything else so that it is really aimed at being engine agnostic and is built on a documented and standard foundation, along with the application being documented, etc. This will mean that 2.x will live for some time while 3.x evolves.
Anyhow, we will be making an announcement about 3.x within 2 weeks or less given certain events that are coming up, so it won’t be much longer and we hope it will be ready to have a much broader set of community members developing for it. (The current efforts are very much community involved also though…)
Good points.
For us the custom context is a necessity, we tried user sets, this is lighter but not powerfull enough for multisite PBX deployment, or simply when there are phones outside of the company linked to the company IPBX. Most of the time those phones need limited access or custom routes for outboud calls.
Another challenge we get with ToIP, is that we do not have caller id update after attended transfers. This is a difficult situation, because Aastra phones do support this since more than one year now, but asterisk 1.4 and FreePBX do not support it. I would be happy to see some efforts in this direction.
Asterisk 1.6.1 do have modifications to support this, but unfortunately, it does cause problems with actual Aastra 2.2.1 xml scripts. So we’ll need to wait certainly about one year more before before to be able to use * 1.6 in production.
Last point, we clearly need an easy way of implementing ANI (or charge number in SS7 words) with SIP telephony. It is needed firstly for urgency services, but as well for billing when a multisite client is linked to the PSTN through VoIP links. SIP Remote Party ID seems to be the way to do this, but standardisation needs to be done. FreePBX could be the leader of this standard.
ANI is supported at level 2 with LLDP-MED protocol, inside Aastra endpoints and Procurve switches, but we need support as well in FreePBX and at VoIP providers to allow for tranmission of ANI from SIP to the PSTN TDM Network.
Olivier.
When you can get VoIP providers to settle on a standard ANI, P-Charge, or what ever header across the board, then we will be all over supporting it. It’s an industry issue … I wish it was just a FreePBX or Asterisk thing.
This answer explain why this situation exist since the beginning of the Asterisk story.
Somebody need to define a simple SIP standard to do this. Providers will follow it, like many end users and providers follow the Asterisk or Freeswitch VoiP train silently.
Remember that Asterisk is the work of 1 person at the beginning. A big story or standard does not need necessarily the aprobation of all the community. If it would need it, then Asterisk and Freepbx will have been stopped by traditionnal telcom providers.
We do not need the full complexity of SS7 translated to SIP. Just a simple SIP identifier and a standard for ANI translation to SS7, independant from the CID name and number we have actualy with regular SIP.
This will permitt to mask or change the CID without loosing the ANI for urgency services. Changing the CID is mandatory as soon as a company is using more than one DID. In this case only the ANI can be used easily for billing or locating.
Most companies using VoIP place themself outside the law because of this ANI lack.