Slashdot Mirror

My 2 cents: If you are using an FXO card, then VM is a no-go. These cards require full attention from the PCI bus in order to operate properly. In particular, I use Digium's TDM800P with Echo Cancellation. There might be other cards out there that are better designed, but I am unaware of them.

However, if you are going straight VOIP using a SIP/IAX trunk and SIP phones, a VM will work just fine so long as you have adequate and stable (perferably redundant) internet access, and your network is properly subnetted or VLAN'd, with a healthy dose of QOS.

But, here's the real reason to not run your phone system on a VM: maintenance. Losing your phone system whenever you have to maintain the hypervisor sucks. So, keep your PBX on dedicated hardware so the only reason to ever bring it down is if there is something actually wrong with the phone system.

Oh yeah, if you are going to use Asterisk, learn dialplans etc and don't use Trixbox, AsteriskNow! or any other Asterisk-based distros. Roll your own and you will be rewarded - even if you have to initially hire a consultant to get your first dialplan. I've started using Debian Wheezy as a base for Asterisk installs. Its nice to have everything all ready for you in the repositories, and at the moment, Asterisk 1.8 LTS with DAHDI and dkms make updates a breeze.

P.S. Please excuse anything stupid - I'm in the middle of a chemo treatment and apparently, my polarity has been reversed.

There is already something in asterix although I think skype tried to kill it.

Skype for Asterisk is dead. Skype killed it, purely by coincidence of course, right around the time things got serious with Microsoft.

I dial 252 (ALArm) from the device I want to be called at, and enter a time at the prompt. At the appointed time, the lovely voice of Allison Smith tells me it's my wake up call and presents me with a random 3-digit number to enter. If I don't answer, hang up, or get the number wrong, I'm called back every two minutes until I get it right. The random number business is necessary because sometimes, if I don't have to do a slightly complex task, I'll just hang up and go back to sleep.

If you're really concerned about Skype support on Linux, then you can set up an Asterisk box and buy the Skype for Asterisk channel http://store.digium.com/productview.php?product_code=1SFA0001 for only $66. That way you can get all the joy that comes with having to keep and maintain your own pet SIP project, and you don't have cut yourself out from the world of Skype users in the process.

Just compiled the latests asterisk from SVN and it WORKS! All my friends can call me at normal handset! I can now call my asterisk from GTalk! At zero configuration! RIP SIP! We barely knew ye... For technically minded: http://svn.digium.com/svn/asterisk/team/phsultan/gmail-voice-video

Having skype integrated into open source PBX [...] would be pretty good...

Asterisk supports Skype. As does FreeSWITCH.

Have you looked at http://packages.digium.com/ or maybe about checking out the svn branch for the version you are using?

You didn't say what distro you use but if it's YUM-capable that might be an option.

Personally, I'm against precompiled binaries for Asterisk. Asterisk source doesn't have any configs all other than samples. It's up to the admin to correctly configure the server. I like sticking to SVN as it allows me to make changes and also stay up to date. It's not perfect and I highly advise regression testing the code if you go that route as svn does sometimes break. Just stay out of the bleeding-edge branches.

IMHO the biggest mistake someone can make with Asterisk and security is downloading the source and doing the "make install samples" portion of the install. It seems like often those are the generic confs I've run across when looking at a pre-existing repo version.

Hand-tuned confs don't load needless modules and also eliminate a lot of security holes. Running asterisk -c over and over again until you get things working does actually suck but in the end is worth the effort. I wonder how many installs out there still have the stupid demo cruft in their production dialplans?

So as is unfortunately typical, some of the quotes I made of course been taken out of proportion. My quote was not that "Asterisk attacks are endemic", but that SIP-based brute force attacks are endemic. Every SIP system that is open to the "public" Internet is seeing large numbers of brute-force attacks. Sites that have weak username and weak password control will be compromised - this is little different than email accounts being taken over by password-guessing systems and used for sending floods of email. The significant difference is that when someone takes over a SIP platform to make outbound calls, there is usually a direct monetary cost, which gets people's attention very quickly. I hear reports of these types of attacks now all the time - it's not unusual, and it's not just Asterisk. We had a blog about this a year ago; this is just a re-packaging of the same news a year later, when recently I unsurprisingly said that attacks are no longer even newsworthy because they're so frequent (hence, the term "endemic".) Apparently, not being newsworthy means... it's newsworthy!

This has little to do with Asterisk other than it happens to be the most prevalent SIP-based platform on the Internet currently. It has everything to do with protocol attacks by script kiddies, or more professional attackers. Bad passwords = easy penetration. The upside on this is that it yet again gets the attention of administrators who might not otherwise know that their password of '1234' might be guessed by criminal users.

The bug that was mentioned? Old news. Really, really old news. And really not even that much of a threat for most people the way they have their systems configured even if they haven't upgraded.

Asterisk, Broadsoft, Cisco, Kamailio, OpenSER, FreeSwitch, Avaya - they're all vulnerable to the brute force attacks if adequate network and username/password security is not implemented. There are ways to minimize, if not eliminate these threats with very standard security policies that should be familiar to any network administrator (ACLs, random passphrases, random client usernames, adequate exception logging, and limits on account usage, to name a few.)

Just as an aside, the Digium SwitchVox platform, which is our commercial re-packaging of Asterisk, has as an element of it's GUI a tool that indicates the relative strength of passwords. We'd encourage any other re-packagers or users of Asterisk to implement a similar UI hint that forces good password behavior by users and local admins. It's really not something that can be done in the core of Asterisk; it has to be done by whatever is the layered UI on top of Asterisk for configuration, or just by good policy.

http://blogs.digium.com/2009/03/28/sip-security/
http://blogs.digium.com/2008/12/06/sip-security-and-asterisk/

John Todd - jtodd@digium.com
Digium, Inc.
Asterisk Open Source Community Director

So as is unfortunately typical, some of the quotes I made of course been taken out of proportion. My quote was not that "Asterisk attacks are endemic", but that SIP-based brute force attacks are endemic. Every SIP system that is open to the "public" Internet is seeing large numbers of brute-force attacks. Sites that have weak username and weak password control will be compromised - this is little different than email accounts being taken over by password-guessing systems and used for sending floods of email. The significant difference is that when someone takes over a SIP platform to make outbound calls, there is usually a direct monetary cost, which gets people's attention very quickly. I hear reports of these types of attacks now all the time - it's not unusual, and it's not just Asterisk. We had a blog about this a year ago; this is just a re-packaging of the same news a year later, when recently I unsurprisingly said that attacks are no longer even newsworthy because they're so frequent (hence, the term "endemic".) Apparently, not being newsworthy means... it's newsworthy!

This has little to do with Asterisk other than it happens to be the most prevalent SIP-based platform on the Internet currently. It has everything to do with protocol attacks by script kiddies, or more professional attackers. Bad passwords = easy penetration. The upside on this is that it yet again gets the attention of administrators who might not otherwise know that their password of '1234' might be guessed by criminal users.

The bug that was mentioned? Old news. Really, really old news. And really not even that much of a threat for most people the way they have their systems configured even if they haven't upgraded.

Asterisk, Broadsoft, Cisco, Kamailio, OpenSER, FreeSwitch, Avaya - they're all vulnerable to the brute force attacks if adequate network and username/password security is not implemented. There are ways to minimize, if not eliminate these threats with very standard security policies that should be familiar to any network administrator (ACLs, random passphrases, random client usernames, adequate exception logging, and limits on account usage, to name a few.)

Just as an aside, the Digium SwitchVox platform, which is our commercial re-packaging of Asterisk, has as an element of it's GUI a tool that indicates the relative strength of passwords. We'd encourage any other re-packagers or users of Asterisk to implement a similar UI hint that forces good password behavior by users and local admins. It's really not something that can be done in the core of Asterisk; it has to be done by whatever is the layered UI on top of Asterisk for configuration, or just by good policy.

http://blogs.digium.com/2009/03/28/sip-security/
http://blogs.digium.com/2008/12/06/sip-security-and-asterisk/

John Todd - jtodd@digium.com
Digium, Inc.
Asterisk Open Source Community Director

Check out the Asterisk software, and specifically the "chan_mobile" extension. It allows you to use a cellphone (with bluetooth) as an "incoming" channel for a phone system, or to use the cellphone as an extension on the phone system. I believe that chan_mobile is included by default in the newest (1.6.x) version of the asterisk software.

Asterisk has a fairly steep learning curve, so it will likely be a time consuming adventure to get it all working, but assuming the bluetooth on your phone supports it, it should allow you to do what you want. You will need to have a Linux computer that has bluetooth, runs the asterisk software, and you will also need an "FXS" port (can be a $15 internal card, or a $30 IP based one) that connects your home phones to the computer.

The voip-info.org site and the asterisk-users mailing list are both invaluable if you are just starting out with asterisk.

If diving into setting up your own asterisk server from scratch is too daunting, it may be easiest to try a prebuilt setup (such as Trixbox CE) and then following one of the guides for adding chan_mobile support to it. I can't personally say how involved this would be, since I've never used any of the pre-setup Asterisk systems.

Good luck!

Verizon and ATT offer SIP trunks already, but they don't push them because they're cheaper than TDM ports. Plenty of other VOIP providers like Aretta and Vitelity also offer them. With G729 over IAX2, though, you can get even more calls down a single T1. Is this news just because Skype is doing it?

Addition:

I suggest that you take a look at http://www.asterisknow.org/ for Asterisk as an appliance.

Add a TDM410 card to be able to connect your POTS line.

The use of a softphone like Express Talk will allow you to use your headset. Some softphones will automatically mute your movie or music when a call arrives.

Sure I have. I also know that supply and demand aren't always (or usually, for that matter) restricted by the government. With IT certifications, there are two obvious ways you can affect supply and demand:

1. Price: If you increase price, you decrease the supply of people that can afford to get your certification. Interestingly, if you set the price too low, too many people will get it, which will cause the demand for that certification in the workplace to go down - this, in turn, will eventually affect the demand for the certification itself. If you set the price high enough, fewer people will be able to afford it, which will cause the HR drones to think there may be value in the certification. This brings me to the next method...
2. Difficulty: Make the test too easy and anyone can pass. This will eventually effect demand for the certification in much the same way that having a low price affects demand. By making the test difficult, you also restrict the supply of people that can pass your certification, which, in turn, helps to boost demand for that certification - if only the best can pass your test, people will assume that only the best passed your test and will hire accordingly.

The key, of course, is to make sure you don't get too carried away in either direction. As I already mentioned, you don't want to make the test too easy or too inexpensive - if you do so, its value in the workplace will be minimal since just about anyone can get it. However, you also don't want to make it too expensive or too difficult - if it's too expensive, only corporate types will be able to afford it, and they have the nasty habit of doing ROI studies on such things sooner or later. If it's too difficult, nobody will want to take the test, especially if the individual's ROI on studying for the test doesn't make it worthwhile. Consequently, supply and demand for certifications is governed by the perceived value of the certification from the workplace, which, in turn, affects the perceived value of studying for and getting the certification for the individual. Also, the perceived value of the product you're getting certified in definitely plays a factor here. Everyone has heard of a "paper MCSE" - they exist because anyone that's interested in IT work "needs" an MCSE to prove they know more than the 15 year old kid down the street, so you have a lot of people studying for that series of tests. However, have you ever heard of a "paper ACSA"? What about a "paper dCAP"? Probably not, because neither Apple OS X or Asterisk are products that HR drones feel represent general knowledge of all IT or phone networks.

That said, you are correct in that, since none of the certifications are required to work on a computer, they do not restrict the supply of people that can work on a computer. This is why Geek Squad is able to pay so little. However, there is a point (and it comes rather quickly) where, if you wish to get past "help desk drone" status, you're going to have to get a small alphabet soup going on your CV. This is similar to how, if you ever want to get past "front office receptionist at a law firm" or "candy striper at a local hospital" status, you're going to need to get some sort of certification.

I saw this, and just had to respond...

As an Asterisk developer, and Digium employee, I felt that I should point out that we're not just selling "super-geeky hardware" anymore.

I'll go ahead and take the karma hit for a shameless plug here.. As of fairly recently, we also have an SMB appliance, and with the recent acquisition of Switchvox - the times are certainly changing (not just for Digium, but for the Asterisk community as a whole). See http://www.digium.com/en/products/hardware/asteriskappliance.php and http://www.digium.com/en/company/switchvox-acquisition-faq.php

Viva la revolution?

I saw this, and just had to respond...

As an Asterisk developer, and Digium employee, I felt that I should point out that we're not just selling "super-geeky hardware" anymore.

I'll go ahead and take the karma hit for a shameless plug here.. As of fairly recently, we also have an SMB appliance, and with the recent acquisition of Switchvox - the times are certainly changing (not just for Digium, but for the Asterisk community as a whole). See http://www.digium.com/en/products/hardware/asteriskappliance.php and http://www.digium.com/en/company/switchvox-acquisition-faq.php

Viva la revolution?

Asterisk (or rather parent company digium) is based in the US (if you consider Alabama part of the US :-), so they potentially could be sued to death. More likely, corporations using asterisk would be sued. Since it's open source, asterisk can be hosted in a country that has a saner patent system. (which might affect corporate usage, but it wouldn't stop me :)

Asterisk can do this rather trivially as part of the dial plans. Get yourself a TDM22B or some other similar card and you can set up anything you want to happen when a number calls in. From forwarding to another number to answering and then hanging up, to answering and asking for a passcode in order to make your phones ring, you can do it with an Asterisk set up.

Maybe try Trixbox for an easy to use, all in one setup of the same. Pop in the Trixbox CD and it auto-installs.

I have a configuration that allows incoming calls during certain times of day and then only from other numbers after those times. So it definitely sounds like what you want to do will be possible with *.

If you install chan_cellphone.so, and you have one of the supported Bluetooth cell phones, you might even be able to build your own GSM to PSTN gateway. No need to buy expensive hardware, or to tie yourself to Skype.

They forgot Digium, the Asterisk company. Its hard to imagine a list of open source innovations that doesn't include Asterisk!

I've built and configured asterisk numerous times. My production server attempt was a dual AMD 64 Opteron but I am having VoicemailMain quality problems. Have you, or anyone else here, who have installed asterisk numerous times, run into anything like this? I can't be the only one. See my email at asterisk forums for more detail. Any insight is appreciated.

Yes, but the difference between typical startups and your ideas is that in typical startups they first have an understanding of how it would make them money -- which for post-1999 VC's is nice to know.

Ok, point taken. However, none of these ideas is entirely speculative; there are companies out there employing some or all of these approaches, among others. Digium is a good example of the model that involves selling both hardware and an
open-source software solution along with training, services, etc.

I should also say that I think a successful open-source company will probably need a combination of approaches. Take RedHat for example: they do "regular" support subscriptions, professional services, training and the hosted systems-management model. Looking at that model as a "whole" you could argue that it is somewhat "proven" now. Of course one could also argue that RH hasn't been around long enough to really "prove" that this model
is viable for the long haul.

"the DoD *really* doesn't like that they don't know who wrote the software, and they also don't like the lack of a central point of contact"

To find out who wrote the software, just read the license agreement ..

Novell Software License Agreement
Red Hat Agreements
Cleversafe Commercial License
Digium End-User License Agreement

"CCEVS evaluation is really REALLY expensive and takes frickin' forever. Now, this is no barrier to Microsoft, which has had enough money and time to get Windows .. evaluated"

"Open source products tend to come with a list of disclaimers as long as your arm"

"Microsoft warrants that the Software will perform substantially in accordance with the accompanying materials for a period of ninety (90) days from the date of receipt" - XP EUAL

Microsoft .. provide the Software .. AS IS AND WITH ALL FAULTS, and hereby disclaim all other warranties .. of reliability .. of lack of viruses .. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THE SOFTWARE - XP EUAL

was Re:What the DoD objects to

Well, yes and no. When OpenPBX was forked, there was a fair bit of hue and cry about suing them for Trademark violation, which they resolved reasonably quickly (sed s/asterisk/openpbx/i) and then there was threats about licence violations by linking to openssl.. I can't find the exact message in the digium archive, but here's a link to the same issue being discussed about the freebsd port.

I tend to think that they're a bit over-protective of their code. They release it as GPL to garner community support, then as soon as someone forks it, they're all upset. That does make me a bit grumpy, but I'm probably just overreacting.

(Whilst I'm not claming a coverup, Digium do have a bit of a history of removing things from the archive - That link, admittedly, is a valid reason to delete stuff from the mailing list archive, but it has happened before)

--Rob

Well, yes and no. When OpenPBX was forked, there was a fair bit of hue and cry about suing them for Trademark violation, which they resolved reasonably quickly (sed s/asterisk/openpbx/i) and then there was threats about licence violations by linking to openssl.. I can't find the exact message in the digium archive, but here's a link to the same issue being discussed about the freebsd port.

I tend to think that they're a bit over-protective of their code. They release it as GPL to garner community support, then as soon as someone forks it, they're all upset. That does make me a bit grumpy, but I'm probably just overreacting.

(Whilst I'm not claming a coverup, Digium do have a bit of a history of removing things from the archive - That link, admittedly, is a valid reason to delete stuff from the mailing list archive, but it has happened before)

--Rob

While I understand what you're saying it makes me wonder what projects you WOULD start if you only look at your current experience. How did you get where you are today? You obviously didn't know everything when you first started. :) Check out the Asterisk forums at http://forums.digium.com./ Using those forums and the Asterisk: The Future of Telephony book from O'Reilly I've learned enough to build some nice systems. Tom

You forgot to mention the fact that Huntsville is heavily religious, conservative and their entire engineering industry is government funded defense.

I'm a software engineer living in Huntsville, and I'm an atheist. I've lived in several other places, and I haven't noticed the religious influence in Huntsville being any more overbearing here than anywhere else. We have our share of bars, strip clubs, and other fun activities for us sinners.

You're right that most of the engineering jobs are DoD funded, but there are still others that are pure commercial. Everyone's favorite VoIP Linux application Asterisk is developed in Huntsville at Digium. I'll see Mark Spencer around town fairly often.

If you're interested in the number of engineering companies in Huntsville, check out this link here.

As with anything, your choice of location is going to be a compromise. Is Huntsville as cool/fun as San Francisco? No. But, my mortgage on a 2200 sq. ft. house is less than $1K a month, and I have a 12 minute commute to the office.

There are plenty of PCI WAN boards with Linux API/drivers on the market. You can get 1-8 port T1, 1-4 port OC3, and 1-2 port ATM and DS-3 boards. Most of them support channelized links, so you can break your T1 into 12 channels for data and 12 digital voice lines.

Here is a list of companies you can get them from:
http://www.sbei.com/ (distributor/products page http://www.ace-electronics.com/Hardware/T1E1J1/t1i ndex.html)

http://www.imagestream.com/Industrial_Cards.html - they even have a 4 port OC3 PCI card

http://www.sangoma.com/main/products/wanpipe - solid Linux support and drivers

http://www.digium.com/ - has 1, 2 and 4 port T1 boards that work GREAT with linux

Of course installation and configuration of this kind of solution will not be as simple as a Cisco WIC in your 2600.

You said:

When I mentioned Asterix to the head of IS, she said it wasn't even an option because "no company can be held accountable for failure".

Uhhh... how about Digium?

Asterisk makes an excellent enterprise grade open-source PBX for the back end.

• RFC-2833 DTMF support is broken | Picking up multiple DTMF using RFC2833
  Asterisk implements DTMF very poorly -- it has no concept of duration or volume of key presses, and is therefore unable to send this information via RFC2833 (commonly used by SIP). Furthermore, the manner in which Asterisk sends DTMF is... unique. Even if you read the standard to mean that the implementation is legal, it's still very strange, and it causes problems with a lot of other SIP hardware.
• Generic jitter buffer for Asterisk (chan_sip implementation)
  SIP has no jitter buffer in Asterisk, making it completely useless if you want to use any Zaptel TDM hardware.
• Its time to start getting T.38 into *
  Asterisk has no T.38 support at all. Want to move to SIP? Want to send and receive faxes? Can't use Asterisk.
• chan_iax2 hangs intermittently
  IAX2, Asterisk's native/favorite VoIP protocol, hangs at random in the latest stable release.
• When jitterbuffer=yes DTMF is unreliable on IAX2 links w/ Asterisk 1.2.1
  Oh, look. DTMF is broken in a different way again. This time over IAX2.

Asterisk makes an excellent enterprise grade open-source PBX for the back end.

• RFC-2833 DTMF support is broken | Picking up multiple DTMF using RFC2833
  Asterisk implements DTMF very poorly -- it has no concept of duration or volume of key presses, and is therefore unable to send this information via RFC2833 (commonly used by SIP). Furthermore, the manner in which Asterisk sends DTMF is... unique. Even if you read the standard to mean that the implementation is legal, it's still very strange, and it causes problems with a lot of other SIP hardware.
• Generic jitter buffer for Asterisk (chan_sip implementation)
  SIP has no jitter buffer in Asterisk, making it completely useless if you want to use any Zaptel TDM hardware.
• Its time to start getting T.38 into *
  Asterisk has no T.38 support at all. Want to move to SIP? Want to send and receive faxes? Can't use Asterisk.
• chan_iax2 hangs intermittently
  IAX2, Asterisk's native/favorite VoIP protocol, hangs at random in the latest stable release.
• When jitterbuffer=yes DTMF is unreliable on IAX2 links w/ Asterisk 1.2.1
  Oh, look. DTMF is broken in a different way again. This time over IAX2.

Asterisk makes an excellent enterprise grade open-source PBX for the back end.

• RFC-2833 DTMF support is broken | Picking up multiple DTMF using RFC2833
  Asterisk implements DTMF very poorly -- it has no concept of duration or volume of key presses, and is therefore unable to send this information via RFC2833 (commonly used by SIP). Furthermore, the manner in which Asterisk sends DTMF is... unique. Even if you read the standard to mean that the implementation is legal, it's still very strange, and it causes problems with a lot of other SIP hardware.
• Generic jitter buffer for Asterisk (chan_sip implementation)
  SIP has no jitter buffer in Asterisk, making it completely useless if you want to use any Zaptel TDM hardware.
• Its time to start getting T.38 into *
  Asterisk has no T.38 support at all. Want to move to SIP? Want to send and receive faxes? Can't use Asterisk.
• chan_iax2 hangs intermittently
  IAX2, Asterisk's native/favorite VoIP protocol, hangs at random in the latest stable release.
• When jitterbuffer=yes DTMF is unreliable on IAX2 links w/ Asterisk 1.2.1
  Oh, look. DTMF is broken in a different way again. This time over IAX2.

Asterisk makes an excellent enterprise grade open-source PBX for the back end.

• RFC-2833 DTMF support is broken | Picking up multiple DTMF using RFC2833
  Asterisk implements DTMF very poorly -- it has no concept of duration or volume of key presses, and is therefore unable to send this information via RFC2833 (commonly used by SIP). Furthermore, the manner in which Asterisk sends DTMF is... unique. Even if you read the standard to mean that the implementation is legal, it's still very strange, and it causes problems with a lot of other SIP hardware.
• Generic jitter buffer for Asterisk (chan_sip implementation)
  SIP has no jitter buffer in Asterisk, making it completely useless if you want to use any Zaptel TDM hardware.
• Its time to start getting T.38 into *
  Asterisk has no T.38 support at all. Want to move to SIP? Want to send and receive faxes? Can't use Asterisk.
• chan_iax2 hangs intermittently
  IAX2, Asterisk's native/favorite VoIP protocol, hangs at random in the latest stable release.
• When jitterbuffer=yes DTMF is unreliable on IAX2 links w/ Asterisk 1.2.1
  Oh, look. DTMF is broken in a different way again. This time over IAX2.

Asterisk makes an excellent enterprise grade open-source PBX for the back end.

• RFC-2833 DTMF support is broken | Picking up multiple DTMF using RFC2833
  Asterisk implements DTMF very poorly -- it has no concept of duration or volume of key presses, and is therefore unable to send this information via RFC2833 (commonly used by SIP). Furthermore, the manner in which Asterisk sends DTMF is... unique. Even if you read the standard to mean that the implementation is legal, it's still very strange, and it causes problems with a lot of other SIP hardware.
• Generic jitter buffer for Asterisk (chan_sip implementation)
  SIP has no jitter buffer in Asterisk, making it completely useless if you want to use any Zaptel TDM hardware.
• Its time to start getting T.38 into *
  Asterisk has no T.38 support at all. Want to move to SIP? Want to send and receive faxes? Can't use Asterisk.
• chan_iax2 hangs intermittently
  IAX2, Asterisk's native/favorite VoIP protocol, hangs at random in the latest stable release.
• When jitterbuffer=yes DTMF is unreliable on IAX2 links w/ Asterisk 1.2.1
  Oh, look. DTMF is broken in a different way again. This time over IAX2.

Asterisk makes an excellent enterprise grade open-source PBX for the back end.

• RFC-2833 DTMF support is broken | Picking up multiple DTMF using RFC2833
  Asterisk implements DTMF very poorly -- it has no concept of duration or volume of key presses, and is therefore unable to send this information via RFC2833 (commonly used by SIP). Furthermore, the manner in which Asterisk sends DTMF is... unique. Even if you read the standard to mean that the implementation is legal, it's still very strange, and it causes problems with a lot of other SIP hardware.
• Generic jitter buffer for Asterisk (chan_sip implementation)
  SIP has no jitter buffer in Asterisk, making it completely useless if you want to use any Zaptel TDM hardware.
• Its time to start getting T.38 into *
  Asterisk has no T.38 support at all. Want to move to SIP? Want to send and receive faxes? Can't use Asterisk.
• chan_iax2 hangs intermittently
  IAX2, Asterisk's native/favorite VoIP protocol, hangs at random in the latest stable release.
• When jitterbuffer=yes DTMF is unreliable on IAX2 links w/ Asterisk 1.2.1
  Oh, look. DTMF is broken in a different way again. This time over IAX2.

Sir,

I have respect for you so therefore I will simply address your concerns and move on. Please be aware that I am not taking my ball and going home. In fact, I currently have 2 or 3 issues open in the Asterisk bug tracker and I now have a policy not to submit any more until older ones are cleared up.

http://bugs.digium.com/view.php?id=5161
http://bugs.digium.com/view.php?id=5162

I am not close-minded and I will use/develop for any software that I find a need for. I still have much more Asterisk code I can submit.

Now, to adress the concerns:

we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.

I believe he is referring to http://bugs.digium.com/view.php?id=3666

This patch did not propose to make the module loader unloadable rather to make it possible to load an alternate implementation of the PBX functionality.

At the time of that posting there was a general agreement that the Asterisk dialplan and the resulting codepath of traversing the PBX needed work but nobody wanted to break the program to fix it. With that patch one could build an alternate PBX callflow engine without disturbing the existing one. This is actually an important idea which i carried to FreeSwitch that the core would only deal with interfaces and pure low-level functionality. And to implement a PBX it would be done in higher level code supplied in the module API. I agree something has to be core and I have thousands of lines of code in my core already.

The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.

This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?

I'm sorry but it is true. Allow me to elaborate with specific examples but before I do, remember, in the previous paragraph I was accused of not wanting anything in the core and now my problem is that I want more in the core.

EXHIBIT A
http://bugs.digium.com/view.php?id=2998

Here is a patch, written by me, that fixes a catch-22 in the Asterisk music on hold caused by the core being dependant on the loadable music on hold module.

The symbols ast_moh_start and ast_moh_stop were referred to in the core in several places and these symbols only existed in the dynamic module object therefore if you did not load the music on hold module the entire application would fail to start. At the time I wrote this patch there were still several other such issues that may or may not have been addressed but it still demonstrates the design issues and the inability to define how the core interacts with the modules.

EXHIBIT B
There is a module called res_features.so which contains the actual code that is executed when two channels are bridged ast_bridge_call and the entire parking concept ast_park_call both of the functions are used in other modules causing a module cross dependancy. Many operating systems will not even let you do this because you must employ lazy linking where 1 dynamic object is forced to trust that certian symbols will exist when the time comes.

soon all the developers will be nothing but users who have no other choice but to try and be developers

It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough l

Sir,

I have respect for you so therefore I will simply address your concerns and move on. Please be aware that I am not taking my ball and going home. In fact, I currently have 2 or 3 issues open in the Asterisk bug tracker and I now have a policy not to submit any more until older ones are cleared up.

http://bugs.digium.com/view.php?id=5161
http://bugs.digium.com/view.php?id=5162

I am not close-minded and I will use/develop for any software that I find a need for. I still have much more Asterisk code I can submit.

Now, to adress the concerns:

we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.

I believe he is referring to http://bugs.digium.com/view.php?id=3666

This patch did not propose to make the module loader unloadable rather to make it possible to load an alternate implementation of the PBX functionality.

At the time of that posting there was a general agreement that the Asterisk dialplan and the resulting codepath of traversing the PBX needed work but nobody wanted to break the program to fix it. With that patch one could build an alternate PBX callflow engine without disturbing the existing one. This is actually an important idea which i carried to FreeSwitch that the core would only deal with interfaces and pure low-level functionality. And to implement a PBX it would be done in higher level code supplied in the module API. I agree something has to be core and I have thousands of lines of code in my core already.

The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.

This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?

I'm sorry but it is true. Allow me to elaborate with specific examples but before I do, remember, in the previous paragraph I was accused of not wanting anything in the core and now my problem is that I want more in the core.

EXHIBIT A
http://bugs.digium.com/view.php?id=2998

Here is a patch, written by me, that fixes a catch-22 in the Asterisk music on hold caused by the core being dependant on the loadable music on hold module.

The symbols ast_moh_start and ast_moh_stop were referred to in the core in several places and these symbols only existed in the dynamic module object therefore if you did not load the music on hold module the entire application would fail to start. At the time I wrote this patch there were still several other such issues that may or may not have been addressed but it still demonstrates the design issues and the inability to define how the core interacts with the modules.

EXHIBIT B
There is a module called res_features.so which contains the actual code that is executed when two channels are bridged ast_bridge_call and the entire parking concept ast_park_call both of the functions are used in other modules causing a module cross dependancy. Many operating systems will not even let you do this because you must employ lazy linking where 1 dynamic object is forced to trust that certian symbols will exist when the time comes.

soon all the developers will be nothing but users who have no other choice but to try and be developers

It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough l

Sir,

I have respect for you so therefore I will simply address your concerns and move on. Please be aware that I am not taking my ball and going home. In fact, I currently have 2 or 3 issues open in the Asterisk bug tracker and I now have a policy not to submit any more until older ones are cleared up.

http://bugs.digium.com/view.php?id=5161
http://bugs.digium.com/view.php?id=5162

I am not close-minded and I will use/develop for any software that I find a need for. I still have much more Asterisk code I can submit.

Now, to adress the concerns:

we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.

I believe he is referring to http://bugs.digium.com/view.php?id=3666

This patch did not propose to make the module loader unloadable rather to make it possible to load an alternate implementation of the PBX functionality.

At the time of that posting there was a general agreement that the Asterisk dialplan and the resulting codepath of traversing the PBX needed work but nobody wanted to break the program to fix it. With that patch one could build an alternate PBX callflow engine without disturbing the existing one. This is actually an important idea which i carried to FreeSwitch that the core would only deal with interfaces and pure low-level functionality. And to implement a PBX it would be done in higher level code supplied in the module API. I agree something has to be core and I have thousands of lines of code in my core already.

The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.

This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?

I'm sorry but it is true. Allow me to elaborate with specific examples but before I do, remember, in the previous paragraph I was accused of not wanting anything in the core and now my problem is that I want more in the core.

EXHIBIT A
http://bugs.digium.com/view.php?id=2998

Here is a patch, written by me, that fixes a catch-22 in the Asterisk music on hold caused by the core being dependant on the loadable music on hold module.

The symbols ast_moh_start and ast_moh_stop were referred to in the core in several places and these symbols only existed in the dynamic module object therefore if you did not load the music on hold module the entire application would fail to start. At the time I wrote this patch there were still several other such issues that may or may not have been addressed but it still demonstrates the design issues and the inability to define how the core interacts with the modules.

EXHIBIT B
There is a module called res_features.so which contains the actual code that is executed when two channels are bridged ast_bridge_call and the entire parking concept ast_park_call both of the functions are used in other modules causing a module cross dependancy. Many operating systems will not even let you do this because you must employ lazy linking where 1 dynamic object is forced to trust that certian symbols will exist when the time comes.

soon all the developers will be nothing but users who have no other choice but to try and be developers

It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough l

Sir,

I have respect for you so therefore I will simply address your concerns and move on. Please be aware that I am not taking my ball and going home. In fact, I currently have 2 or 3 issues open in the Asterisk bug tracker and I now have a policy not to submit any more until older ones are cleared up.

http://bugs.digium.com/view.php?id=5161
http://bugs.digium.com/view.php?id=5162

I am not close-minded and I will use/develop for any software that I find a need for. I still have much more Asterisk code I can submit.

Now, to adress the concerns:

we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.

I believe he is referring to http://bugs.digium.com/view.php?id=3666

This patch did not propose to make the module loader unloadable rather to make it possible to load an alternate implementation of the PBX functionality.

At the time of that posting there was a general agreement that the Asterisk dialplan and the resulting codepath of traversing the PBX needed work but nobody wanted to break the program to fix it. With that patch one could build an alternate PBX callflow engine without disturbing the existing one. This is actually an important idea which i carried to FreeSwitch that the core would only deal with interfaces and pure low-level functionality. And to implement a PBX it would be done in higher level code supplied in the module API. I agree something has to be core and I have thousands of lines of code in my core already.

The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.

This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?

I'm sorry but it is true. Allow me to elaborate with specific examples but before I do, remember, in the previous paragraph I was accused of not wanting anything in the core and now my problem is that I want more in the core.

EXHIBIT A
http://bugs.digium.com/view.php?id=2998

Here is a patch, written by me, that fixes a catch-22 in the Asterisk music on hold caused by the core being dependant on the loadable music on hold module.

The symbols ast_moh_start and ast_moh_stop were referred to in the core in several places and these symbols only existed in the dynamic module object therefore if you did not load the music on hold module the entire application would fail to start. At the time I wrote this patch there were still several other such issues that may or may not have been addressed but it still demonstrates the design issues and the inability to define how the core interacts with the modules.

EXHIBIT B
There is a module called res_features.so which contains the actual code that is executed when two channels are bridged ast_bridge_call and the entire parking concept ast_park_call both of the functions are used in other modules causing a module cross dependancy. Many operating systems will not even let you do this because you must employ lazy linking where 1 dynamic object is forced to trust that certian symbols will exist when the time comes.

soon all the developers will be nothing but users who have no other choice but to try and be developers

It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough l

(though I'm not sure if that actually works with Asterisk - I doubt it ;)

Asterisk is missing SIP over TCP support and TLS encryption, there is a patch for it, but it's post 1.2.

Our company has ported over our primary phone numbers (including 800 numberes) to Teliax http://www.teliax.com/ recently (we were with Vonage, but had constant dropped calls, and clarity issues). It's a great little VoIP company that offers IAX and SIP termination. They allow unlimited simultaneous calls via one account (along with outbound callerid specification/spoofing), and you are simply charged their $0.02/min rate for both incoming and outgoing calls, plus $5/mo per line. Highly scalable and stable, though a reliable internet connection is a must (we have 18Mbps at our disposal). Obviously, we use Asterisk, but there is no obligation to do so, any SIP-compatible offering should work fine. So far Teliax has been extremely reliable, though they are undoubtibly a very small company, but you also get fast/personalized support from their main engineers, not the teir 1 support idiots companies stick you with [*cough*Vonage*cough*].

Anyhow, that's just my experience. If you don't already have the bandwidth to spare though, it's probably not the right path for you (though bandwidth saving codecs like g726 [instead of g711 ulaw/alaw] will help conserve bandwidth while keeping call clarity, but possibly adding latency) ... One other recommendation is to retain one POTS/PSTN line for 911 calls, it's doubtful any VoIP company will have that down soon, and you don't want internet connectivity to prevent 911 calls in an office environment... you may already have one for Faxing, since no VoIP provider I've seen yet offers T.38 for faxing, though it appears asterisk may be getting some support soon http://bugs.digium.com/view.php?id=5090 so Teliax will probably have support for that once it's in!

The poster didn't mention how many phones/lines they need, but if they need to they can use VoIP internally (for unlimited internal phones), and just hook up T1s from the POTS for as many voice lines as they need (if they are worried about the voice quality/potential unreliability of VoIP providers). Digium has Quad-span T1 cards with onboard echo cancellation, so it should scale to the number of lines that are needed.

I've switched to using http://asterisk.org/ along with http://www.broadvoice.com/rates_compare.html. I think you'll find this Wiki to be a very useful resource: http://voip-info.org/

The plan I'm using is BYOD-Lite which costs me only $6 a month and there was no activation fee, since I had my own VOIP equipment in the form of an Asterisk PBX installed on Linux. From what I can tell, they are one of the few providers who allow the use of customer supplied VoIP hardware/software, in my case Asterisk.

Something you'll have to research is what technology you want to use for hooking up individual phones to Asterisk. One possibility would be to use hardware from Digium: http://www.digium.com/index.php?menu=product_categ ory&category=hardware or any other Analog Telephone Adapter (ATA), or you could use Softphones installed on employee PCs such as X-Lite (free), or similar.

Good Luck!

http://www.gloryhoundz.com/

They've silently changed the EULA it seems. My information is old. The new one is much better. There was much controversy over the old EULA.

There used to be one big EULA for RHEL, and it did state that you must not have any RHEL servers installed without RHN. It didn't give you the option to run unsupported copies, period. If you bought one copy, you were bound by the EULA automatically since it came with services. If you wanted to install RHEL on another computer, the only way you could do it without violating the EULA was to buy another seat from them.

Here's some text from the old EULA:

"If Customer wishes to increase the number of Installed Servers, then
Customer will purchase from Red Hat additional Services for each
additional Installed Server."

"During the term of this Agreement and for one (1) year thereafter,
Customer expressly grants to Red Hat the right to audit Customer's
facilities and records from time to time in order to verify
Customer's compliance with the terms and conditions of this Agreement"

Link
Another Link
Yet another

You can see there was plenty of talk about this questionable EULA, I'm not making it up.

I'm glad to see they have a much better set of EULAs in place now. They are still pretty pricey for what you get.

I put all my phone numbers on the "Do Not Call Registry" in the US, and have experienced a great reduction in the number of telemarketing calls, but, the Do Not Call registry does not apply to Charitable institutions, and a few others, and the volume of these calls has grown exponentially over the months... it seems the charities sell each other their call lists, and if you give anything to one, soon you will have them ALL calling at regular intervals.

I've been playing with Asterisk for a couple of years now. I've implemented every privacy option in my dialplan, and have finished the coding of the call filtering option, and had it incorporated into the 2.x releases.

First the 3-tone is played (the da-dee-doo that precedes "The number you have called is no longer in service!", if no CallerID is present.

Next, if no CallerID is present, and the autodialer has not hung up, the calling party is forced to supply a phone number, or the call is terminated, and if they are stupid, and give my number instead of theirs, the call is "terminated with prejudice".

Then, they get a menu, where they must choose the person with which they would like to converse. They get music on hold, and if no answer, they are thrown into voicemail.

One of the first menu options they are presented with is a number to press if they are telemarketers. This option runs them into what I titled the "Telemarketer Torture Script". (See http://www.voip-info.org/wiki-Asterisk+Telemarkete r+Torture)

I have complete CDR logs of the incoming and outgoing calls, and have totalled up how many calls and from what sources, and at what stage each call was terminated.

And I found that each measure I implemented removed a fairly small percentage of the callers, with the total result that I have not received any telemarketing calls or requests for donations in almost two years now.

The single most effective measure is the menu prompts. It defeats autodialers, which aren't programmed to answer prompts. It somehow defeats all the rest of the live callers, who don't seem to have the courage to ignore the telemarketing option, and choose a person. Only once has a charity ever been brave enough to actually select my extension, and in that case, all they did was thank me for past contributions, and hung up.

My conclusion is, that if you truly want to eliminate unsolicited calls from your business/home, you need to implement a simple IVR menu system.

A more detailed explanation of the privacy measures are outlined in http://lists.digium.com/pipermail/asterisk-cvs/200 5-July/006992.html

And, some details of my research results are in: http://lists.digium.com/pipermail/asterisk-users/2 004-September/062571.html

Best of luck!

I put all my phone numbers on the "Do Not Call Registry" in the US, and have experienced a great reduction in the number of telemarketing calls, but, the Do Not Call registry does not apply to Charitable institutions, and a few others, and the volume of these calls has grown exponentially over the months... it seems the charities sell each other their call lists, and if you give anything to one, soon you will have them ALL calling at regular intervals.

I've been playing with Asterisk for a couple of years now. I've implemented every privacy option in my dialplan, and have finished the coding of the call filtering option, and had it incorporated into the 2.x releases.

First the 3-tone is played (the da-dee-doo that precedes "The number you have called is no longer in service!", if no CallerID is present.

Next, if no CallerID is present, and the autodialer has not hung up, the calling party is forced to supply a phone number, or the call is terminated, and if they are stupid, and give my number instead of theirs, the call is "terminated with prejudice".

Then, they get a menu, where they must choose the person with which they would like to converse. They get music on hold, and if no answer, they are thrown into voicemail.

One of the first menu options they are presented with is a number to press if they are telemarketers. This option runs them into what I titled the "Telemarketer Torture Script". (See http://www.voip-info.org/wiki-Asterisk+Telemarkete r+Torture)

I have complete CDR logs of the incoming and outgoing calls, and have totalled up how many calls and from what sources, and at what stage each call was terminated.

And I found that each measure I implemented removed a fairly small percentage of the callers, with the total result that I have not received any telemarketing calls or requests for donations in almost two years now.

The single most effective measure is the menu prompts. It defeats autodialers, which aren't programmed to answer prompts. It somehow defeats all the rest of the live callers, who don't seem to have the courage to ignore the telemarketing option, and choose a person. Only once has a charity ever been brave enough to actually select my extension, and in that case, all they did was thank me for past contributions, and hung up.

My conclusion is, that if you truly want to eliminate unsolicited calls from your business/home, you need to implement a simple IVR menu system.

A more detailed explanation of the privacy measures are outlined in http://lists.digium.com/pipermail/asterisk-cvs/200 5-July/006992.html

And, some details of my research results are in: http://lists.digium.com/pipermail/asterisk-users/2 004-September/062571.html

Best of luck!

So, just like any other GSM base station, you need a BSC (Base Station Controller) and a gateway MSC (which Asterisk _might_ be able to manage with some hacking - does Asterisk speak SS7?)

Umm... it didn't a short time ago...

google could save 4b on the purchase price of skype and buy digium to get asterisk instead - which interoperates with all the major voice protocols (sip, iax, h323, mgcp but not skype at present). Asterisk is approaching version 1.2 at a breakneck clip.

When you can get an Handytone http://www.grandstream.com/y-htseries.htm/ or IAXy http://www.digium.com/index.php?menu=product_detai l&category=hardware&product=S101I/ type device anyway? I mean, really, get a job, these things only cost $100.... Oh, yea, and feel free to start the ususal rant about proprietary systems and how much they suck......it is skype right? Or is it only lame when proprietary isn't free?

A modem is designed to interface with the phone line, not the phone handset, so a normal modem won't help you talk to a handset at *all*. This hack is designed to use the speaker and mic of a phone as the input and output of a sound card. Nothing more. Most voice modems are only half-duplex, so they won't help you, either. If you had a fancy full-duplex voice modem, it would allow you to replace the entire sound card, but then you'd have to make Skype work with that instead.

Basically, what you're asking for is what is called an FXS interface (not an FXO, as others have mentioned in this thread). They do exist: they make one, for example. However, they're not inexpensive. This cable costs less than $7: that's hard to beat.

Would you have some links that illustrate what you're talking about? As soon as I finish posting this, I'm going to be googling "sidetone coil"! But if you or anyone else have any other thoughts...

Unless you're purely talking about enhanced hybrid to separate conversion circuits. *Those* I've seen, but that's not what we need. That's internal to the board, and we don't get to play with that! :) However, anything that allows us to improve the connection between the board and the POTS line, particularly in the area of impedance matching, wouldbe *much* appreciated.