I wonder if FreePBX will ever work with FreeSWITCH?

General Help
1

For those who don’t know, FreeSWITCH is an alternative to Asterisk, that’s not nearly as well know. For anyone who may be interested, here is a comparison of FreeSWITCH and Asterisk.

The reason I ask is because the FreeSWITCH folks tend to be breaking new ground, doing things we can only dream about in Asterisk, particularly with regard to wideband audio. For example, today they posted this:

The FreeSWITCH development team has struck again! FreeSWITCH now supports CELT, a new open source audio codec that allows for CD-quality transmission with VoIP. CELT is described as an “ultra-low delay” audio codec that supports both voice and music. 48kHz VoIP can be carried in 48kbps of bandwidth!

Putting this in perspective: CD-quality audio is 44.1kHz. This means CELT supports better than CD-quality audio in a VoIP environment! The only bad news here is that you might need to upgrade your headset so that your microphone is sensitive enough to handle such a wide range. Also, consider bandwidth usage: 48kHz of super high-quality audio requires a mere 48kbps of bandwidth. By comparison, the venerable PCM mu-law codec, G.711u, consumes 64kbps of bandwidth and yields only 8kHz audio quality!

(Remainder of article here).

And a couple of days ago they noted that they are now supporting Polycom’s G722.1 and G722.1C Codecs (Siren).

I know other have asked about this but I just wondered if any serious efforts were under way to make FreePBX compatible with FreeSWITCH?

2

Yes

3

That’s a very good news as we are tired of Asterisk 1.4 reliability problems :

  • thread lookup because of localized DNS problems causing all trunks and extensions to unregister

  • iax trunk never registering again after WAN connectivity problems

According to Anthony, leader of the Freeswitch project, those problems are well known to him and Freeswitch code structure has been careefully optimized to avoid them.

More Freeswitch will permit us to do easily what was very complicated to do with Asterisk.

For example, doing a true “Paging / Switch to Intercom” system will be easy to do with Freeswitch, where it need a complex feature application map and conference management with Asterisk.

4

Both Asterisk and FreeSWITCH will have their strengths and weaknesses. FreeSWITCH has the benefit of hind site while Asterisk has the benefit of millions of installations, many many features and years of usage. Having two good engines out there will be great for all and neither one is going to stop evolving and improving.

5

Yes you are right. Except that Asterisk since 4 years do not help a lot full ip telephony users and providers.
When you first read the first edition of “Asterisk, the futur of telephony”, you have the feeling that Asterisk will become fastly “the” IPBX software changing the world. This is not the case two years later. The world is far from switching to full IP telephony, because a lot of problems subsist. Freeswitch is better. It does have a more serious basis to become the Futur of Telephony. I think that the staff behind Asterisk is responsible of this, because they do not listen for users enough, and do not have a serious SS7 and traditionnal telephony knowledge. This seems normal as the most important for them, is that asterisk support correctly their TDM hardware.

A telephony software is not only a piece of code, it is as well a very good understanding of the traditionnal telephony world, to find the right way to migrate or use together traditionnal telephony and IP telephony. Asterisk poorly fail in this regard (no bandwith management for example, we have this in the ATM world since decades).

Another example : we still have no standard solution for sending ANI through SIP. There is still no difference inside asterisk between ANI and CID at the SIP level. ANI is mandatory for interfacing the SIP world to the SS7 world at the country and world scale. Without a serious standard ANI transmission method, final clients and providers using IP telephony do not respect the law in most country and do not give urgency services the level of geolocalization required.

For Asterisk we still have reliability problems and compatibility problems at each new version. Asterisk still does not support HD telephony correctly, still does not negociate codecs smartly, still does not support IPv6. Next year we’ll begin to need IPv6 support. We need an IPv6 compliant software now to be ready at time.
More and more we are using full IP telephony, and in this context Asterisk is very bad at negotiating codecs correctly.

Freeswitch is a new basis for a real opensource project. I hope it will become the new baby of telephony developpers fastly.

The telephony world need reliable softwares, Asterisk is not. Period.

Olivier ADLER

FRANCE IP

6

Your comments indirectly prove my point.

You have found a lot of issues with Asterisk that effect the way you want/need to use it (many of which are completely irrelevant for many applications). With FreeSWITCH you don’t have such a laundry list for a good reason, it has not been around long enough to determine its pros and cons. It has a lot of promise and potential though, which makes it exciting to track.

I wish both engines the best of luck and am confident that they will bot evolve and continue to get better, to all of our benefit.

7

Asterisk is a PBX not a class 5 switch. SS-7 support is irrelevant in a PBX, you seem to be confusing a carrier switch and a PBX for customer premise.

ANI over SIP is an IETF RFC issue not an Asterisk issue. Asterisk supports many call control protocols in addition to SIP.

Asterisk 1.6 had g.722 wideband CODEC support for ‘HD’ voice.

IAX2 trunks have no problem re-registering when a connection is lost. In fact I have many customers with redundant Internet and the IAX trunk recovers nicely after failover.

The DNS issue is a quirk and only show it’s head in installations with improper DNS infrastructure.

Asterisk needs to focus on Enterprise PBX feature sets, not esoteric carrier features. There are several commercial SS-7 stacks for Asteisk that are Telcordia certified for interconnection to the provider SS-7 networks.

In my opinion Asterisk needs more mechanisms for high availability, shared extension appearances (not SLA), and a more robust manager interface. That is my short list.

Once we get FreePBX stabilized on the 1.6 train we can take advantage of the multiple parking lots and other improved Asterisk applications.

8

One reason I’d love to see FreeSWITCH used, besides the additional functionality it offers, is that I just cannot imagine they’d let the bug that is the basis behind Ticket 3199 (which, at its core, is an Asterisk problem - I was just hoping FreePBX might provide a workaround) exist through several major versions. That is the problem with Asterisk, they seem to have become so bureaucratic that bugs don’t get fixed, and new features take forever to add.

9

Ticket 3199 - Just took a look, if you register the trunk that is exactly what happens, the DNS is checked at every re-register.

This functionality has also been improved in 1.6

129 * Added DNS manager support to registrations for peers referencing peer entries.
130 DNS manager runs in the background which allows DNS lookups to be run asynchronously
131 as well as periodically updating the IP address. These properties allow for
132 better performance as well as recovery in the event of an IP change.

10

SkyKing OH, I’m going to nitpick several of your comments. :slight_smile:

I don’t think Asterisk should necessarily limit itself to being just a “PBX” switch. The lines between PBX and Carrier switch have always been somewhat blurry anyway, even in the traditional telephonty world (remember Centrex?).

ANI over SIP is an issue if there is support avaliable and users want it. If FreeSWITCH (or some other software) offers it and Asterisk doesn’t, that’s a reason not to use Asterisk.

Asterisk is a bit late to the party on wideband voice (I refuse to call it “HD” voice, that’s a ridiculous construct).

Who cares what IAX2 trunks are capable of if your upstream providers only offer SIP? Oh, sure, you might say “don’t use such carriers” - which is fine advice as long as there isn’t a significant difference in price. But for many users, the choice is “do I use a SIP connection to Carrier A that offers cheap rates, or an IAX connection to Carrier B who has a significantly more expensive rate?” If you say you’d pick carrier B anyway, then you are in the minority (or you are spending someone else’s money).

You say, “Asterisk needs to focus on Enterprise PBX feature sets, not esoteric carrier features”, but of course that would be on your short list. Other people may have completely different ideas about what Asterisk should do. I suspect that Asterisk is being used in carrier-type applications far more than you might realize. And as I said, in today’s world the line between user and carrier can become fairly blurry, especially in larger installations.

Of course you are entitled to your opinions about what Asterisk needs, as are all of us. I’m not saying your short list is a bad one; those are probably good ideas. But, just hypothetically speaking, suppose that the FreeSWITCH people implemented those things while Asterisk was still sitting and stagnating? My fear is that unless Digium figures out a way to cut the red tape (and, possibly, get around the mindset of some of their current developers) they are going to get left in the dust. They will be the Commodore Amiga of telephony: The system everyone remembers with great fondness after we’ve all moved on to something different (and in most respects better).

The other thing to keep in mind is that if FreePBX chooses not to support FreeSWITCH, at some point someone else will probably develop a FreePBX-type program (or possibly a fork of FreePBX itself) that does. On one level FreeSWITCH is doing everything right. From what I have read, I doubt that FreePBX (at least initially) will drop support for Asterisk and embrace FreeSWITCH exclusively, so you will still have to option to use FreePBX with Asterisk 1.6 and probably versions beyond that - HOWEVER if Asterisk continues to descend into stagnation, at some point there will be no good reason to support it anymore. It’s really up to the Asterisk folks whether they want to become more responsive to what users want (and to what the competition is offering), or to die a slow death.

11

Yes Asterisk or Freeswitch is not limited to final client use. I know here a lot of providers using it, and most of our providers have Asterisk machines.

Using full IP telephony avoid using expensive traditionnal telephony trunks (E1, BRI or PRI), and save the cost and complexity of expensive ToIP bridge hardware.

In the case where we deal with multisite client installations, and using full IP telephony (SIP or IAX trunk to the provider) we have to deal with ANI transmission. If not, as soon as the client mask its CID, the provider has no means to get the proper client ANI in the trunk. Then the call can be terminated without ANI, causing problems to urgency services, or billing problems if the client need independant billing for each location.

IAX trunk mode is the only simple solution to save bandwith when using G729. That is one of the reasons why providers have some asterisk machines to deal with a large number of calls even for clients using small ADSL or DSL links. It’s possible to send about 50 G729 calls or more in an IAX trunk on a low cost ADSL2+ link. In this case, the link between the client and provider is fully IP, there is no traditional telephony link transmitting an ANI.

We should be able in this case to set an ANI for each client location, and an independant or masked CID. So the provider could see the right ANI anytime in the final client trunk (a multisite client will have one ANI for each location, but can have many CID for each location). All this needs to be transmitted in the final trunk to the provider.

SS7 take care of this. Inside SS7 ANI is the Charge Number. ANI is a generic term of the past but we are using it for simplicity, because it does not have the same name inside each protocol.

A solution is to use SS7 over IP between the client and the provider, but this is far too complicated and expensive for most cases.

The futur of telephony is not here yet. When IPBX softwares and IP telephony switches will be able to communicate a bit better with the SS7 world, then we’ll be able to start a true and efficient migration. As of today, with Full IP telephony, service quality drop down because we have to deal with a high number of interoperability problems. It is not rare today to see 3 or 4 codec translations for the same call, destroying audio quality. I would be curious to see what would arrives if today we were suppressing all the SS7 hardware inside telcom providers and replacing by SIP softswitches. For sure, we would have a big disaster, with enormous billing problems, codec negotiation problems, and bandwith problems.

There is no need to reinvent the wheel, just see what has been done inside SS7 and traditionnal links (ATM technology), and smartly translate to IP. Reading the RFCs is not sufficient. A big effort is necessary to implement them reliabily as the RFCs allow for to much interpretation and do not cover enough SS7 / SIP interoperability problems. Most SS7 / SIP interoperability documents are only old drafts done by isolated engineers.

Big providers are very happy to see the slow developpement of SIP / SS7 interoperability, because they are not yet ready to switch to IP at client sites. This is a fantastic opportunity for them to prepare the future and see the small providers fighting with erratic SIP communications :=(

I hope that the opensource telephony community will soon understand this and start to developpe smart things like intelligent codec negotiation, bandwith and call priority (an urgency call should be able to drop an active call inside an IP trunk to allow to terminate it, a saturated trunk should stop accepting new calls automatically), really test and debug the new 16, 32 and 48 Khz codecs, and more generaly implement reliabily all the basic things working since decades in the traditionnal telephony world be fore to put toys for geeks like Asterisk does.

12

I am going to comment in depth this evening.

I have spend my carrier (almost 30 years) in the traditional telco world and my last roll was in product management at Motorola in the softswitch division. We made significant contributions to 3GPP however Charging number over SIP is still not part of any ratified SIP or 3GPP RFC’s.

Most of the functionality you describe in the final paragraph is related to admission control and should be managed by the Session Border Controller. Open Source has not built a functional SBC (Admission Control and Charging Gateway. The Acme Packets Net-Net devices is one of my favorite devices.

I am a huge proponent of custom premise IAX trunks. In fact it’s the majority of my business today.

13

I’m a huge proponent of electric cars. Doesn’t mean the roads are going to be filled with them anytime soon (though one can always hope!).

Point is, in the real world, people are using SIP, and will continue to use SIP. In fact, I would bet there’s more interest in Skype trunks right now than in IAX. Don’t get me wrong, I like IAX and love the fact that it eliminates most firewall-related issues, but let’s be realistic here - for whatever reason, most providers choose to offer their services using SIP.

I actually have a theory as to why that is, though I may be wrong. My suspicion is that it’s driven by the desire to support the lowly VoIP adapter, 99% of which support SIP only. Granted, you CAN buy an IAXy type device (or a Chinese knockoff that even supports two lines) but very few people do. Since providers have to support SIP for their SIP endpoint users, it’s much easier to just use SIP all around (actually it isn’t, due to the aforementioned firewall issues, but providers just don’t seem to grok that).

If Linksys could be persuaded to provide firmware for the PAP-2 that would support IAX - which should be possible if they could be persuaded to do it - I’ll bet you would find providers starting to embrace IAX, especially when they find out that all the complaints about one-way audio suddenly go away when IAX is used. But in the meantime, we have to deal with what’s out there now, not what we wish were available.

14

wiseoldowl -

SIP actually is not a problem with a Session Border Controller, that’s how all the providers are able to offer hosted SIP phones such as the Linksys or Polycom.

The world revolves around SIP and as you point out I would love to have Asterisk based system represent more that the fraction of 1% of all IP based PBX’s in service but today that just isn’t so.

15

Let me comment about IAX :

IAX is good for NAT : yes but most of the time it is not a big challenge to use SIP even through a NAT router. In the near futur, Ipv4 will be replaced by IPv6 at client locations, where NAT will disapear.

IAX is good for trunks, because it does agregate channels inside one IP frame, saving a lot of bandwith for low bandwith codecs like G729. For interoperability reasons, it is better to stay G711, it is actually the only reliable method to get a clear audio path between providers, but some clients ask G729 to save bandwith. In this case using IAX is really better for bandwith savings. The standard SIP protocole does not allow trunk mode.

And the bad things :

IAX does gives more signalisation problems : SIP error codes translated to IAX and back to SIP through different PBX or switches give mapping problems. In the end the client can have strange error reporting. Those errors are not important most of the time for small systems. But as soon as you are using more than one provider trunk for reliability reasons at the client location, it is very important to have a strong signalisation, specialy for the distinction between busy and congestion. If not, the IPBX will not be able to choose the right trunk, or loose time trying to terminate busy calls on each trunks because of congestion reporting instead of busy reporting. This is a big problem today, as a lot of providers do not deliver a strong signalisation, neither SIP, neither IAX. Big telcom providers are very happy of this because this amator signalisation keep professional clients to the high margin traditionnal telephony side.

IAX is not largely supported. Even Digium dropped IAX, the only IAX device is the IAXy device, today unavailable. This small FXS was performing quite bad, has never been updated since a long time, has a quite bad sound quality, and does not detect reliabily european pulse dialing (a use where it could be interesting for old phones collectors). More it has only US tones available… There are chinese IAX phones, very bad hardware as well, with a buggy firmware written by beginners.

Very big problem : there is no serious realtime call quality and traffic analyzer supporting IAX… This is a very big problem for serious providers. The only toys available are low cost software analyzers, giving eroneous or bogus results for jitter values and other call metrics. Next IAX does not report a full set of call quality metrics like RTCP XR does. RTCP XR does report MOS LQ call quality directly from the terminal device. RTCP XR is implemented on good quality SIP hardware and can be easily extracted from IP traffic in real time with well known software or hardware analyzers.
Another important problem with IAX is that there is absolutly no analyzer available to get MOS PESQ analyzis on test calls. MOS PESQ is important to diagnose IP telephony from end to end. MOS LQ means nothing when there is more than one trunk on the call path. We absolutly need MOS PESQ for serious call quality measures, specially when the calls terminates or initiates from the PSTN world.

IAX is using UDP for signalisation, this can produce call drop problems when using it over unreliable links. SIP can use TCP. IAX can produce missed calls (unavailable destination) when the IP link drop packets more than 0.5 - 1 %. SIP over TCP will not suffer from this. (the last time i tried SIP TCP on Asterisk 1.6 it was fully not working).

IAX is not easy to deal with for protocol extensions, SIP is easy, adding SIP headers directly in the dialplan.

All this tends to push away IAX from the serious telephony world. I will say that the only real benefit of using IAX is the trunk mode for G729.

Olivier ADLER
FRANCE IP

16

This has to be one of the more interesting threads I have read in a while.

The Wise Old Owl asks Philippe “If FreePBX will ever work with FreeSwitch?”

Philippe says “Yes.”

and off we go in to the wild blue yonder…

The implications are fairly staggering if you think about it. My understanding is that as FreePBX continues to develop, we will have a choice of engine while using familiar tools to manage Asterisk or FreeSwitch installs as we see fit.

That this will increase the FreePBX projects survivability aside, we the VoIP integrators get more tools. All goodness from my point of view.

17

It also speaks to FreePBX’s flexibility.

The XML structure of FreeSwitch’s configurations is quite different than Asterisk. In some ways easier to work with.

Essentially this will split FreePBX into two code trains. Resources are always a concern. I would hate to see the Asterisk 1.6 integration pace slow. There is so many new features to integrate from 1.6.

Once the two trains leave the station feature parity between them will double the workload.

18

Watching at the last development year of FreePBX, it semms that developpers do not have enough ressources (or money ?) to implement important new functions like Dial Contexts.

Supporting a new engine seems to me difficult for the FreePBX team, if they do not find a serious sponsor and enough money. Saddly the code has become very complex for external programmers to give help.

TCAPI is a starting GUI project for Freeswitch. Seems a good thing as well. We’ll see in the few next monthes if Freeswitch is really a new story start, but seing the responsiveness of the Freeswitch team, quality of the actual code, and cooperation with well known hardware manufacturers like Polycom, there is no doubt that Freeswitch has a good chance to become an important challenger very fastly, or could even kill the Asterisk mastodon in a couple of years. This depend mainly from the availabilty of a good GUI interface (for final client sites) and a good XML editor (for carriers) to mask the complexity of XML dialplan programming (most telephone guys do not like XML).

I do not see any reason to not switch fastly to Freeswitch, at least for client sites at beginning, as soon as a complete GUI interface will be available. This will give us a better reliability and an easier path to implement multitenant IPBXs. This will give us the possibility as well to use better codecs like the new opensource CELT or Siren G722.1 with Polycom hardware, at least for internal calls because the world is not ready yet for something different than G711.

For small carriers, it will be more difficult to replace Asterisk because of billing applications developped for it, but when it will be possible, they’ll get for sure a large reliability and scaling benefit. On a machine where Asterisk support 100 simultaneous calls, Freeswitch can support 1000 simultaneous calls. This is a clear advantage for a switch. Then we’ll see for sure medium sized providers replacing their high cost Cirpak by inexpensive Freeswitch machines.

Olivier ADLER
FRANCE IP

19

I think carriers are the first place that will look at FreeSwitch first although the lack of AIX authentication is a big issue for me.

We need to look at what PBX features will map 1 for 1 to FreeSwitch. I think you may find quite a gap.

As far as resources - FreePBX has the funding from Bandwidth, do you not consider that significant? I am excited and can’t wait to see what happens with FreePBX this year.

Maybe Philippe will make a comment (hint hint) about the FreeSwitch train.

I have no idea why everyone is excited about wideband voice CODEC’s. I can see perhaps in conferencing applications. g.711 are optimized for human speech. I actually find it harder to understand normal speech on wideband CODEC’s. I have certainly never had a customer request the feature. That includes my Cisco customers who have had wideband handsets for several years.

20

Yes you are right, some wideband codecs are not very nice. I’ve tested G722 on Aastra phone, this codec has a wider bandwith, but does not give a natural sound like G711.

We are not excited. It is simply a natural extension to the very old 3.5 kHz bandwith. Did you ever listen to music through the phone ? Seriously 3.5kHz bandwith si simply not enough to get a good sound. 7 Khz bandwith is ok for music and is possible with 16 Khz codecs. 7 khz bandwith give as well a better voice recognition and gives “s” and “F” letters a really better transmission. With 3.5 Khz bandwith only, it is very commun to make mistakes between “s” and “f” when listening for spelling.

The euro ISDN standard is supporting 8 kHz bandwith since many years, but the switch has never append.

SIP telephony is nice because it does allow to use more bandwith for internal calls, waiting that carrier do accept them for external calls.

Anyway, we can think that in the futur ENUM will bypass totally carriers, and this will be a good thing, because they are actually a big source of headache for VoIP telephony (bad audio quality because of audio path using multiple codec translations like double or triple G729 or G729 to GSM, DTMF transmission problems, special numbers reachability problems, unreachable destinations problems, billing problems…). We are using ENUM for interclients calls and we never have those kinds of problems. Enum permitt large bandwith calls beetween clients without problems, and even H264 video calls. Not possible most of the time with carriers.

In this regards, Freeswitch is an interesting alternative to Asterisk because it does support good quality large bandwith codecs.

G711 16 KHz or similar quality codec is the way to go, not the old G722 codec used inside Asterisk.