I wonder if FreePBX will ever work with FreeSWITCH?

No I tend to listen to music on the stereo (or the stereo speakers on my computer) not on my phone.

I had this same experience with the sales guy at the Verizon, I recently updated to a Blackberry Curve touchescreen. He is telling me all the wonderful things the phone can do, however the phone itself is difficult to use, it take three keystrokes to bring up the dial pad. I think we can so caught up in extending the functionality of a phone we forget the primary purpose of the device.

As far as ENUM you are preaching to the choir. At Motorola my team was responsible for the Wateen (Pakistan) VoIP deployment. We used a highly resilient ENUM infrastructure on Solaris that provided all e.164 to SIP URI translations. We had seamless dialing between E.164, SUP URI and TEL URI numbered endpoints.

Yes ENUM (or domain name dialing) is a good solution for VoIP. It could fully change the telephony world because carriers will disappear with it.

But a new job can appear with Enum : IP providers could sell directly to the final clients advanced national and international QOS services for telephony, so that each client could join correctly an IP Enum destination without jitter problems.

Using Enum does technically simplify a lot call routing and give a clear audio path without multi codec translation problems, generally make things more reliable, and suppress the cost and reliability concerns of centralized carrier call routing platforms.

Enum replace the expensive routing power of softswitches by the native routing power of internet IPv4 or IPv6 protocol.

Enum reduce the communication cost to the cost of the necesssary bandwith for calls, even for internationnal calls.

We are using it every day and a call has never been lost by Enum. this is not the case with our telephony providers.

Olivier ADLER

Certainly peer to peer calling has its place and maybe someday we will all call each other over our Internet connection. Certainly we are doing this today with ENUM and DUNDI and even private peering between Asterisk systems.

Current ENUM RFC’s do not support CODEC enumeration, nor would participate in traffic classification for QoS.

Asterisk and FreeSwitch give a tremendous amount of freedom to the users to mess up the CODEC setup. Multiple translations between very low bandwidth CODECS to ADPCM can cause terrible voice quality. Fore example if you peer two sites with GSM and then the carrier translates to g.723 you will have terrible audio quality.

End to End CODEC ‘Chain of Custody’ may become a reality. The question then becomes if you want to allow inbound connections to select the CODEC they use.

Even a simple G729 to GSM translation gives a bad sound quality.

We are fighting every weeks with small carriers using G729 to save bandwith. They give a terrible sound quality for calling GSMs because of the G729 - GSM translation.

The simpler today to keep a correct sound is to stay G711 from end to end. This is possible with most VoIP carriers.

G729 or other low bandwith codecs should only be used at final client locations, when bandwith savings are mandatory.

Those having listened a milliwatt test signal through a G729 codec will understand where is the trouble with G729 after more than one transcoding…

The conclusion is that it is not tolerable to see carriers using G729 and similar codecs.

Here is an interesting table with MOS scores for different multi translations setup where we can see clearly the audio degradation :

Codecs MOS score

G.711 (PCM) 4.1
G.729 3.92
G.723.1 3.65
GSM 3.5

G.729 x2 3.27
G.729 x GSM 3.17
G.729 x3 2.68

We can see that G729 + GSM is quite bad, and G729 three times is unacceptable audio quality.

Unfortunately it is frequent today to see call setups where dual or triple translations occur.

Oh, Olivier…

(stepping up on high horse)

Having dialplan’ed a Freeswitch system by hand (actually a VMWarwe, Hosted instance and actual box) I know first hand that it takes a while to get up to speed in how things work. Unless you are a devote of Freeswitch, I personally don’t think anyone should be rushing this to their client sites. Maybe I am a bit slow on the take, but I worked with Asterisk/FreePBX for 18 months before I unleashed it on my clients.

So, as near as I can tell the FreePBX project is easing into FreeSwitch support in a careful and deliberate manner. A manner that will yield positive results over time.

If you have really been watching FreePBX development what you would have noticed is the most active period in the projects history.

You might have also noticed the rather huge recent development of Bandwidth.com becoming a sponsor/benefactor of the FreePBX project.

Yes? No?

We all have little “wishes” that we wished got developed. Just because this feature or that didn’t make the cut… It doesn’t mean that nothing is happening.

(sliding off the horse…)

Anyone have an update on the FreePBX FreeSwitch project?


There was not even a response to the request for an update posted over two months ago. This combined with the fact that discussions of a FreePBX interface for FreeSwitch started over a year ago. I have been watching and waiting patiently during this time, but now I have to wonder. So much time has passed without any kind of a public preview/beta and conversations seem to be dwindling.

Has this effort died?

There will be an official announcement within the next 2 weeks. Consider that period coincides with Cluecon which is in 2 weeks :slight_smile:

Oh boy, oh boy, oh boy … possibly a pbx-Christmas in August???



Well it’s been just a little over two weeks since the hint of an upcoming announcement. With Cluecon 2009 starting in just about 5 hours (I would be there if I didn’t have unmovable commitments), here’s hoping that something comes early in the conference. Maybe at 10am during Anthony Minessale’s talk? Or maybe at 11:30 in one of the TBA slots?

As I wait for some kind of an announcement, I think my dreams tonight will be full of dancing sugar plum fairies and elegant FreeSwitch GUI’s.


Tomorrow (day 2 of conference) :slight_smile:

Wow … the squirrels have been squrrelling and the woodchucks chucking!

I don’t know if I can contribute at this dev-preview stage, but when this gets to a good-beta or rc edition, my sweat-equity is there for early-adopter use/testing!!!

Congratulations on the milestone, but moreover for taking a risk, and for the leadership in this space.


I’m super happy to see the FreePBX v3 announcement.

I’m very confident in the FreePBX / Freeswitch community to give us a better VoIP futur.


In parallel to this project, i think that it is now important for VoIP telephony to define rules for providers as well as fitter / final users, specialy level two and level three providers.

Interoperability with SS7 world is important as well mainly for billing as there is today a lack of support for special numbers from VoIP providers.

But there are other important problems as well, like the absence of standard in the VoIP world for ANI (charge number in SS7 world) transmission from the caller to the final called party. This gives problems for urgency services, and law conformity. LLDP-MED is the first standard at level 2 ; ANI origination at the switch level, but this needs to be extended at level 4, using for example SIP remote party ID in a standardized way from the client IPBX to the provider. This ANI needs to be transmitted as well through SIP providers, and converted to the SS7 charge number when the destination is a PSTN number.

Another problem is codec compatibility. We absolutly need to use G711 codecs from end to end at the world scale. Too often, we have a terrible audio quality because of a double or triple conversion from / to G711 to G729 or GSM. This need to be standardised, providers should not have the possibility to use G729.

G729 should be used exceptionnaly at a final client site, when G711 cannot be used for bandwith reasons.
To often, we see peoples using G729 for no reasons, even at provider level. This is terrible.
When a party is using G729 or other lossy codec, the full call path need to switch to this codec (passthrough), to avoid multiple conversion. This is mandatory for audio quality. Most of the time this is not true today, with or even without providers in the audio path, because neither softwares neither providers do respect rules for this. Codec negotiation needs to work from end to end, or if not, stay G711 from end to end.

It is terrible to see that hardawre manufacturers begin to implement HD voice, when we still have many problems with 8 KHz VoIP.

Cluecon and similar evenements are nice and important, but it is very important as well to define simple rules at the world scale for interoperability and quality of VoIP.

We hope to see the FreePBX project give simple advices at those levels, for example in the GUI itself by small textual advices.

Last, Enum needs to be used to begin the PSTN to Full IP VoIP transtion. Enum is a transition technology, before using true URI dialing. It is strange to see that URI dialing is more common than Enum. Enum is realiable. Often more reliable than VoIP providers.

Then we’ll have a true alternative for the actual PSTN network, not before. And the change from PSTN to full IP VoIP will really begin to happen.

The market will greatly change as well with the full IP transition, with less money for PSTN and VoIP telcom providers / manufacturer, and more money for VoIP fitters, IP link providers, and VoIP software programmers.

Thanks for your listening,

Olivier ADLER

to remove

What a wonderful post! I really agree. I need reminders of this, too.

We are going to be adding some features shortly to expose more advanced functionality. I think, even in the advanced sections, I will try and add some help that describes how we advise you to set certain settings to get the best performance.

I’ll try and bump that up in priorities.

Someday I hope we have an auto-configure that asks what you’re DOING with the product first, then installs a stock set of settings. But that’s a ways away.

Keep you posted. Thanks for the feedback & support, for sure.

  • Darren Schreiber