MWI NOTIFICATION IN ASTERISK
Need Ideas
Anyone that has ideas, feel free to let me know, shoot me an email at amdtech@mdaniel.net and I’ll write about it. Also, I may be looking for people to keep the blog updated as well with their experiences and ideas so there’s more information from other people.
MWI Notification
Asterisk MWI is an interesting animal. Most people don’t realize that the MWI light is turned on simply by the presence or absence of the msg.txt files in the voicemail user’s directory. Using the method I’m outlining here will allow you to keep the load light on any call servers and have the voicemail server(s) handle notification and voicemail storage. This method is also immediate, since every time a call is made, Asterisk does the processing and sending of the MWI instead of a cron job that’s run every X minutes.
The first thing you’ll need is the notify_vmail_extern.sh script:
#!/bin/bash
CONTEXT=$1
EXTEN=$2
NUMVMS=$3
SCMCMD="/usr/local/bin/notify_extern.sh $CONTEXT $EXTEN $NUMVMS"
ssh ${SERVER} "$SCMCMD" > /dev/null 2>&1 &
This script goes on the voicemail box(es). Asterisk automatically
sends the three arguments to the externnotify script, so don’t worry
about those, just make sure your script has them. The SCMCMD is
actually the script and controls that will be run on the other servers
as well. The ssh command is what actually does the notification. You
can have as many of these in here as necessary to send notifications
out. If your phone is registered to only one server, you can probably
do some creative lookups based on the arguments (either a db lookup for
location information based on extension). If the phone can be
registered anywhere, you can just put a series of ssh commands in to
send the command to all the servers at once.In order for that script to work, you must have ssh keys from the user Asterisk is running under on the voicemail box to the user that Asterisk is running under on the other machines. That is outside the scope of this article.
Next, you’ll need the script that runs on the call servers that will be doing the final notification:
#!/bin/bash
CONTEXT=$1
EXTEN=$2
NUMVMS=$3
NOCMD="rm -f /var/spool/asterisk/voicemail/$CONTEXT/$EXTEN/INBOX/*"
CREATECMD="mkdir -p /var/spool/asterisk/voicemail/$CONTEXT/$EXTEN/INBOX"
if [[ $NUMVMS = "0" ]]; then
$NOCMD
else
$NOCMD
$CREATECMD
for ((count = 1; count <= $NUMVMS; count++)); do
if [ $count -lt 10 ] ; then msgcount=000$count
elif [ $count -lt 100 ] ; then msgcount=00$count
elif [ $count -lt 1000 ] ; then msgcount=0$count
fi
TOUCHCMD="touch /var/spool/asterisk/voicemail/$CONTEXT/$EXTEN/INBOX/msg$msgcount.txt"
$TOUCHCMD
done
fi
This script is pretty straightforward. All it does is take the
arguments sent, parse through the number of voicemails, and dependent on
how many there are, either create that number of message files, or
delete them outright. This process is about as immediate as the ssh
comand can get.Finally, on the voicemail server, edit the voicemail.conf file and configure the externnotify option like this:
externnotify=/usr/local/bin/notify_vmail_extern.shIn Asterisk, do a reload app_voicemail.so and you’re done :) Watch and make sure that it’s working.
UPDATE: In response to comments below, Asterisk 1.4 switched to checking for specific lengths of the msgXXXX.txt file name, so the old script didn’t work anymore. The update in blue above makes it work with later versions of 1.4.
Conversion Blues
December 4th 2006I figure I’ll go over a few considerations we have had to take before undertaking something of this size. I won’t say it’s huge, but it’s not small either, with about 7000+ possible endpoints. Asterisk is a free product, granted, but it’s still a drop in the bucket when you’re doing a single shot system-wide replacement of this many phones.
Early estimates are putting us at about $2.5M, which I guess would be kinda conservative (jeesh, I wish I had this much money). This number involves the upgrade of every single network switch under a Cisco 3750 on the main Administration part of our network, i.e. Not Dorms. Once you have the switch capability, you can start working on the infrastructure and making sure that the switches can run your phones for an extended period of time, hence, you need a UPS. Our average uptime in the event of failure is about 2 hours, which someone higher up deemed was the best length of time to allow for. This infrastructure evaluation can also involve the evaluation of the server system as well as any upgrades required to get features you require. Finally, consider the phones, and what you need for your system.
The phones are what puts the project at the $2.5M number. Let’s say you go for full scale replacement of every single endpoint with an IP phone. That’s where the magic comes in, since you’ll be dropping at LEAST $100 for each phone, with a little more for certain featuresets and users that like to have “pretty” phones that do more. I think our numbers put us at about $1M for the entire phone order. That’s fun.
Now take into consideration that students don’t really need pretty IP phones, do they? Personally, I would rather bring my own phone, especially if I could use a cordless one. This brings something I wasn’t too thrilled with when I first started working on this project: Analog Converters. There are a number of options here, some of which are somewhat elegant, some are a little too risky from the hardware side. You could either go out and get several thousand “personal” converters, let’s say at $50 a piece, but the problem here is the control is with the user, not the sysadmin. Or you could go the Citel route (which converted me, they make some really awesome analog/digital-converters). At about $100 a port, this is more expensive than the personal converter solution, but much cheaper than the IP phone solution, since you don’t have to have the UPS support you require with the IP phone solution since these devices take up FAR less power than a full dorm of IP phones.
I’m not sure where this path is headed, but things finally seem to be coming together for our particular Asterisk installation. I’m definitely hoping it goes smoothly, and hope they actually go through with this system wide replacement.
Conversion Blues
Conversion Blues
I figure I’ll go over a few considerations we have had to take before undertaking something of this size. I won’t say it’s huge, but it’s not small either, with about 7000+ possible endpoints. Asterisk is a free product, granted, but it’s still a drop in the bucket when you’re doing a single shot system-wide replacement of this many phones.
Early estimates are putting us at about $2.5M, which I guess would be kinda conservative (jeesh, I wish I had this much money). This number involves the upgrade of every single network switch under a Cisco 3750 on the main Administration part of our network, i.e. Not Dorms. Once you have the switch capability, you can start working on the infrastructure and making sure that the switches can run your phones for an extended period of time, hence, you need a UPS. Our average uptime in the event of failure is about 2 hours, which someone higher up deemed was the best length of time to allow for. This infrastructure evaluation can also involve the evaluation of the server system as well as any upgrades required to get features you require. Finally, consider the phones, and what you need for your system.
The phones are what puts the project at the $2.5M number. Let’s say you go for full scale replacement of every single endpoint with an IP phone. That’s where the magic comes in, since you’ll be dropping at LEAST $100 for each phone, with a little more for certain featuresets and users that like to have “pretty” phones that do more. I think our numbers put us at about $1M for the entire phone order. That’s fun.
Now take into consideration that students don’t really need pretty IP phones, do they? Personally, I would rather bring my own phone, especially if I could use a cordless one. This brings something I wasn’t too thrilled with when I first started working on this project: Analog Converters. There are a number of options here, some of which are somewhat elegant, some are a little too risky from the hardware side. You could either go out and get several thousand “personal” converters, let’s say at $50 a piece, but the problem here is the control is with the user, not the sysadmin. Or you could go the Citel route (which converted me, they make some really awesome analog/digital-converters). At about $100 a port, this is more expensive than the personal converter solution, but much cheaper than the IP phone solution, since you don’t have to have the UPS support you require with the IP phone solution since these devices take up FAR less power than a full dorm of IP phones.
I’m not sure where this path is headed, but things finally seem to be coming together for our particular Asterisk installation. I’m definitely hoping it goes smoothly, and hope they actually go through with this system wide replacement.
Fonality vs. Digium
Speaking as a user of Asterisk in a large environment compared to Fonality’s average install, most of his arguments about why his company’s decisions are “correct” are blown way out of proportion. I’m going to have to agree with Marcelo’s concerns on this one, even in the face of Chris’s responses refuting most of them (or downplaying the concern people should rightly feel). Fonality’s product sounds like a catch, and it’s no wonder that small businesses are calling them up for phone systems, but I think Fonality is playing russian roullette with their customers systems.
Marcelo’s arguments are definitely straightforward and his responses are to the point, some would even say they’re correct. I’m going to argue from my standpoint some of the issues covered. I’m not interested in a point for point bulletin as these are going to overlap and address some of the arguments stated.
- Security and Management – It is not the PBX designer’s job to manage the phone system. Historically, larger companies house their own telecom system and manage their own extensions. Hell, we have a Meridian that we manage fully in house. Companies aren’t stupid, the only reason they’re picking the VoIP solutions over anything is that it’s definitely cheaper and brings them into a whole new realm of possibility. Digium hands over the software in a box just like any software company does, and doesn’t require direct access to the servers. And for the strong willed, there’s even a gasp open source edition that’s… free??!!?? Granted, setting up Asterisk is definitely not for the faint of heart, but with the advent of the Appliance, they’ve got a GUI Framework that is also gasp open source. Seems to me that we’re getting closer and closer to what Fonality is offering.
- Call Detail Records – I’m not sure where Chris is getting his arguments about the use of CPU cycles and such. We’ve been running our databases in tangent with our Asterisk systems along with call detail processing without any issues, period, and we’re running PostgreSQL which is more memory intensive than MySQL is. Ethics aside, I’d like to see the Federal Regulations that state that the information that Fonality is receiving (I’m assuming without the companies even knowing) is protected from their involvement. Who’s to say that they’re not looking at the detail records.
- Hosted Services – Chris argued that all the hosted services would have the same questionable problems that Fonality is being questioned about now, and I’m going to disagree with that one. Vonage, just to name one, is by law considered a Phone Company, they are bound by federal regulations (Marcelo did state that, didn’t he?) about how they handle their services and customers. Also, that’s a whole different ballgame. Fonality handles the internal company systems, not the global communications of the company. Honestly, is it so hard for them to release control of the systems their customers bought and provide patch support and such to the customer?
- Ease of use – This is also a moot point. Digium offers consulting and there are many contractors out there that will get a system up and running and turn over control without any uplink to “central” servers. These services are even to the point where the only time they would have to come in is if the customer wanted a massive restructuring of their system. Case in point, the entire development team of our system would be fully satisfied with leaving their post for an extended period of time without having to worry about the kind of stuff that Fonality is expecting their customers to fail in their capabilities on.
Polycom vs. Cisco
| Feature | Polycom | Cisco | |
|---|---|---|---|
| 1 | Remote control | Web interface, Phone configuration file overrides | Limited configuration file options |
| 2 | Secretarial Functions | Available for when Asterisk supports it | Not available |
| 3 | SIP Compliance | Yes | Limited |
| 4 | Licensing | None required | New versions require CCM |
| 5 | Fully featured across the board | Yes | No |
| 6 | Unified Configuration | Yes, exact same configuration files across the line | No, each site in the line has a different type of configuration (flat file, xml, and binary) |
| 7 | Functional SIP Firmware | Yes | Limited |
- Remote control
- We've had several issues in the past where user's forwarded their phone to a number that is only useful if accessed by the person AT the phone, not being forwarded in. The only way to disable these functions and bypass the internal functions was to physically be at the phone. There is NO other way to do this remotely, which can cause a management nightmare, especially if you have several people in remote locations. With the polycoms, there are several different options for resetting functions, be it through the web interface that comes with the phone, or through the configuration files that the phone uses. We can control almost every aspect of the phone and how it works from the server without need of physically being at the phone, aside from doing hardware checks. This includes SIP compliant functions such as parsing SIP headers for control information about specific calls (the intercom function comes to mind, you can’t remotely auto answer a Cisco phone, but you can with a Polycom).
- Secretarial Functions
- Although the Cisco Call Manager supports shared line appearances (this is the main one, I don't know what other options the meridian has), the SIP version of the firmware does not allow this. This ties in with the crippled firmware (number 7). The Polycoms come stock with the functions we'll require to get SLA (shared line appearances) and BLA (busy line appearances) working, once it is fully supported by the backend (BLA currently does work, but it's not stable enough in our current version to use widely).
- SIP Compliance
- This is more related to the newer versions of the phone than to the 7940/7960's. The 79x1's all have Call Manager specific code embedded in the firmwares, making them more difficult to troubleshoot and get working on the Asterisk platform. For instance, the 7970/1's that we currently have do not have the correct NAT support required to work with Asterisk, don't support authentication passwords, and are riddled with Call Manager specific configurations in their subsystem. Another point on the Cisco phones is that their newest 7940/60 firmware images do have Cisco Call Manager specific code, but it hasn't interfered with the configurations as of yet. The Polycoms are designed from the ground up to work with a SIP compliant server, therefore their configuration is as simple as telling them what server to talk to, whether they're behind a NAT or not, and what to register as with what password.
- Licensing
- The newer Cisco phones don't have a “general” sip firmware anymore. There is a note on the information site that states “All Cisco Unified IP phones require the purchase of a phone technology license, regardless of call protocol being used.”. The polycoms as stated before are designed to be run on third party SIP servers, so this point is moot for them.
- This point may be less important depending on how Cisco wants to approach our particular setup, however, when it comes down to it, it would make more sense to use phones that aren't designed for any particular server and can be ported from one system to another if we end up not liking the system we've chosen.
- Fully featured across the board
- All the Cisco phones have different types of options and features. If I stick a 7912 on someone's desk, and then set a 7940 on their desk, and then later set a 7970 on their desk, they'll have to relearn the phone structures and options all over again. The Cisco's are not consistent in their interfaces, which makes it much more difficult during upgrades and modifications to allow the user to be more comfortable with modifications to the system. This is definitely apparent with a switch from CCM 7940's to SIP 7940's. This is also related to the “crippled” SIP firmware (7). However, we can drop a Polycom 430 on someone's desk, and then when they decide they need more call capacity, drop a 501, and then a 601 later on down the road, the interface is almost exactly the same from phone to phone, as is the underlying featureset. The only thing they have to learn is how to deal with more lines per phone than with where the options went and what the phone does or doesn't do now.
- Unified Configuration
- The different Cisco IP phones have different kinds of configurations. For each version of phone we decide to install, the provisioning system has to be modified to include that new version. The 7940/60's have a couple of flat files that control them, the 7912/15's require a binary conversion from text files, and the newer phones require XML files. With every upgrade, the firmware loads are different and are not consistent across the board. Every time a firmware comes out, we have to figure out what the upgrade path is and figure out why a phone won't upgrade when the rest of them worked just fine. This quickly becomes a management nightmare. The Polycom's have a single unified sip.cfg file that controls every aspect of the phone, from the codecs it's allowed to use, to what each button does, for EVERY single phone in the line. Then each phone can have an override file, which is based on mac address. If I have to replace a Polycom phone with a newer version or a larger number of lines/screen, all we have to do is change the name of the configuration file and that new phone is configured, in moments. The upgrade path for the Polycoms is much easier as well, as all you have to do is drop the latest SIP firmware in the ftp directory and the phone pulls the latest version of that and the configuration files, and then you're done, no more headaches with upgrades since the process is more streamlined and universal.
- Functional SIP Firmware
- The Cisco SIP firmware only really goes so far as allowing you to answer the phone, conference another person in, and do call waiting. One of the features I get complaints about is the ability to dial without picking up the phone. Another one that is mentioned from time to time is that the phones no longer support idle XML services, as well as a very stripped down XML parser that doesn't allow us to do the kind of dynamic features in the services button that we could with the SCCP firmware. However, the Polycom's are fully featured across the board, they all have a limited XHTML browser built in, and although it won't look as pretty on the smaller 430's as on the larger 601's, the functions will be exactly the same across the board.
Voicemail App Modifications
Included in this patch:
- "From User" functionality
- This function allows us to send voicemail FROM the user that left the message, so you can just click reply when you receive the email
- "MP3 Conversion"
- This function converts the voicemail to mp3 format before emailing it to the user, providing more application saturation and not requiring special codecs in most cases.
- "Volume Gain"
- This increases (or decreases) the volume of messages that are emailed.
- "Forward Compatibility"
- I call this compatibility since it makes forwarding the message act the same as regular voicemail messages do. The original handling was that it would be dropped in a user's inbox and the forward function does all the work. I didn't write the patch, but we do have it in place and working and I didn't realy think it was necessary to remove it from the patch file.
Table "public.emaillookup" Column | Type | Modifiers ----------+-----------------------+----------- cidnum | character varying(10) | email | character varying(60) | cidname | character varying(60) | username | character varying(15) | exten | character varying(5) |And in extconfig.conf:
[settings] emaillookup => odbc,ast_cnf,emaillookup ; use your standard db connection here
Aside from that, if anyone has any questions, let me know.
Volgain patch for asterisk v1.2
The version we use on campus also converts to mp3 for better client support, as well as a number of other patches if anyone would be interested in that. Just post a comment and I’ll see what I can do.
In order to install the patch, run these commands:
cd /path/to/asterisk/source
patch -p0 --verbose < /path/to/volgain.patch
make
make install # you can run this or just copy app_voicemail.so
# from apps to /usr/lib/asterisk/modules and restart asterisk
<edit>Sorry guys, I left a section in the code that was part of our CONVERTMP3 function, it’s been removed.
<edit 2>
Alright, I’ve updated the patch to work in 1.2.32, for those of you still on 1.2. I’d recommend switching to 1.4 or 1.6 even, as the patch you’re looking at here is actually part of the source code in future versions.
No comments:
Post a Comment