As a follow-up to my Asterisk 1.8 encryption fun, I wanted to check out Asterisk 10 and see if I could get SIP-S and SRTP working. I fired up an antique Celeron box with 512MB of RAM with the FreePBX distro CD. An hour later, it was running Asterisk 1.8 and I was talking between extensions. No encryption yet.
At this point, I started to appreciate PBX-in-a-Flash a little more because that distro does a full ./configure, make, make install for Asterisk and Dahdi. The stock FreePBX distribution doesn't, but it does get things up and running quick.
After getting FreePBX running, I downloaded libsrtp and Asterisk 10. I had the same trouble with libsrtp in the Asterisk ./configure as before, so Google the error and add -fPIC etc. to the Makefile. After a couple of attempts, Asterisk finished configuring and making and installed and started. I could make calls back and forth.
However, when I first added tlsenable=yes and a path to my certs to my sip_general_custom.conf and restarted Asterisk 10, it did nothing for TLS. Asterisk wasn't even listening on port 5061. And AES encryption on an IAX2 trunk back to my production Asterisk box failed with the following error:
WARNING[1248] /usr/src/asterisk-10.0.0/include/asterisk/crypto.h: AES encryption disabled. Install OpenSSL.
OpenSSL was installed. On further investigation, I discovered that the res_crypto module was not loading or loadable.
OpenSSL-devel was not installed. So I went back and did a yum-install openssl-devel and recompiled and reinstalled Asterisk 10. Then TLS worked fine.
For the record, here are the packages I installed for Asterisk 10 on a FreePBX 2.9.0.9 distro. Dahdi and Asterisk-Add-Ons are not covered here.
zlib-devel-1.2.3-3.i386
libxml2-devel-2.6.26-2.1.2.8.el5_5.1.i386
sqlite-devel-3.3.6-5.i386
doxygen-1.4.7-1.1.i386
keyutils-libs-devel-1.2-1.el5.i386
e2fsprogs-devel-1.39-23.el5_5.1.i386
libsepol-devel-1.15.2-3.el5.i386
libselinux-devel-1.33.4-5.5.el5.i386
krb5-devel-1.6.1-36.el5_5.6.i386
openssl-devel-0.9.8e-12.el5_5.7.i386
mysql-devel-5.0.77-4.el5_5.4.i386
Another thing: You can add your SIP parameters (like tlsenable=yes) to the SIP configuration page that's available in FreePBX now, instead of hand-editing /etc/asterisk/sip_general_custom.conf.
Next: An selinux policy for Asterisk?
Showing posts with label asterisk. Show all posts
Showing posts with label asterisk. Show all posts
Sunday, January 15, 2012
Saturday, January 7, 2012
Asterisk Encryption Gotchas
Finally, Asterisk supports encryption of phone calls and signalling in version 1.8. It's about time. So now, those of us running FreePBX can just hit the encryption checkbox and everything will run fine. Not so much. FreePBX 2.9 incorporates encryption options for extensions, but it assumes you've done all the legwork and configured all the prerequisites. (Tested with varying levels of success on Asterisk 1.8.1.1, FreePBX 2.9.0.7, Bria 3.2.1 62387 (iPhone version works fine, too), snom370-SIP 8.4.32, Aastra 57iCT/3.2.2.1136, and Xlite 4.0.9). My Asterisk install is based on PBX in a Flash, but I do my own recompiling, which pretty much voids its warranty and script upgrade functionality. So proceed at your own risk. (Since this is Asterisk, though, you knew that already.)
To get encryption running in Asterisk, take things step by step. Asterisk encryption is really two types of enrcryption: SIP-S, or SIP over TLS for signalling -- traditional PKI using OpenSSL; and SRTP for the voice traffic. Each is configured independently under each extension. Asterisk Encryption is not end-to-end. It is extension-to-Asterisk, and maybe Asterisk-to-Asterisk on trunks. Asterisk encryption is not foolproof, and it will not encrypt calls to the PSTN. It's still vulnerable to MITM attacks with faked certs, and to a compromise of your Asterisk install. Also, just because your connection to Asterisk is encrypted and the lock symbol shows up on your phone doesn't mean the other extension (or trunk) on the other side of Asterisk is also secure.
The key for SRTP is exchanged over the SIP channel, so if SIP's not encrypted, what's the point of bothering with SRTP? If you want to see what you're missing by not using encryption, download Cain from oxid.it and run it while you register the Bria softphone client and make a call from your windows computer. You get hashes of your SIP passwords and recordings of your phone calls, all from a GUI Windows program. If you have a network tap or span port in the right spot, you can intercept every call and signal between your Asterisk server and its SIP endpoints.
To get started, Asterisk 1.8 requires libsrtp. (You can thank Cisco for making it available, too.) You'll need to download, configure, make, make runtest, and make install before you hit ./configure on your Asterisk source. (Yes, recompiling Asterisk is necessary.) Then, when you do ./configure on your Asterisk source, you'll get an error when it finally gets to checking your libsrtp availability. Google the error phrase, and you'll learn what to change in the CFLAGS line of your libsrtp Makefile. Recompile and reinstall libsrtp, then reconfigure Asterisk. Then in your Asterisk source, make menuselect and select libsrtp under resources. Don't forget to make sure your other cool Asterisk features (like gtalk) are still enabled before you save and exit. Then recompile and reinstall Asterisk. There are plenty of tutorials for these steps on the Interwebs.
Once Asterisk is running again, you can start by getting a certificate for TLS. I am not going to do yet another certificate from self-signed CA howto here. There's an excellent one over at madboa. It's nice for Asterisk to now include a CA/Cert script, but you should really understand how SSL works. I know people who send private keys via email.
Another note about certificates: even if all your workstations are in a friendly LAN with the same DNS suffix, use the fully-qualified Domain Name (FQDN) for your Asterisk certificate. Some endpoints (Bria, I'm looking at you) require FQDN and cannot validate the certificate if you're getting to your Asterisk server by a short name. Using IP addresses for the registrar in your endpoints? That won't work either. You'll need the CA cert on some endpoints but not others. (Snom phones like certs in DER format; Asterisk and Aastra like PEM. To copy from PEM to DER, try this:
openssl x509 -in input.crt -inform PEM -out output.crt -outform DER
Once you get your CA and certificate, your sip_general_custom.conf file should have lines as follows. (In FreePBX, sip_general_custom.conf is the one you can hand-edit safely.)
tcpenable=yes ; If you don't have TCP enabled for SIP now, go ahead and enter this and test it.
tlsenable=yes
tlsbindaddr=0.0.0.0
tlsclientmethod=tlsv1
tlscertfile=/etc/asterisk/keys/asterisk.crt ; concatenate the key file to the bottom of the cert file so they're together.
tlscafile=/etc/asterisk/keys/asteriskCA.crt
tlscipher=AES256-SHA:AES128-SHA:RC4-SHA:RC4-MD5;
Some say put "ANY" there for tlscipher. I suggest you want encryption that's strong but compatible with your endpoints. For valid strings, look here: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS. To see which one your endpoint is using, you'll need to do a network capture via Wireshark. If there's no shared cipher between your endpoint and Asterisk, you'll see something like this in your logs:
/var/log/asterisk/full:[2012-01-03 13:59:30] VERBOSE[29926] tcptls.c: == Problem setting up ssl connection:
error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
Also, you'll need to trust your self-signed CA in Linux. (Seriously, don't set tlsdontverifyserver=yes -- it's just lame.)
If you're on Fedora or CentOS, the folder is /etc/pki/tls/certs.
# ln -s myAsteriskCA.cer `openssl x509 -hash -noout -in myAsteriskCA.cer`.0
then verify:
# openssl verify -CApath /etc/pki/tls/certs /etc/asterisk/keys/myAsterisk.cer
should get you a:
/etc/asterisk/keys/myAsterisk.cer: OK
Once you have a certificate in place, restart Asterisk and see what comes up:
/var/log/asterisk/full:[2012-01-02 23:37:26] VERBOSE[24700] tcptls.c: SSL certificate ok
Then you can try connecting with TLS. In FreePBX, you go to the particular extension you want to test and select TLS Only and reload. Each endpoint is different. Once TLS is successful, you can try setting the extension to use SRTP encryption in FreePBX.
Notes on Phones:
Each phone is different. Bria was easy, so you may want to start with that to see if Asterisk is working correctly. In account settings, domain needs to be a FQDN that matches what you've assigned the certificate. You also need to import the your CA cert into Windows' CA certificate store. For signaling transport, select TLS. For SRTP, select "Make and accept only encrypted calls" for Media Encryption. With any luck, when you hit the apply button, you should see "All accounts are active." While Bria for Windows validates certificates, it's optional on the Bria for iPhone/iPad.
The other software phone, 3CX, has settings for TLS but gets caught in an SSL handshake loop when trying to register, in spite of a shared cipher suite.
For the SNOM 370 to connect via SRTP successfully, I had to set RTP/SAVP to Mandatory. (Identity | RTP in the Snom Menu.) If you have multiple SIP accounts to the same Asterisk server in your SNOM phone, having any one ID configuration incorrect can break them all (Error message "Not acceptable here" whenever you dial). Also set the SRTP Key to 80-bit; 32-bit is the SNOM default, which doesn't work. (This has changed in Asterisk 10: Add option encryption_taglen to set auth taglen only 32 and 80 are supported currently.)
Also, disable RTCP support in SNOM if you don't want Asterisk to crash when it's doing SRTP.
user_host1!: my.asterisk.net;transport=tls
user_host2!: my.asterisk.net;transport=tls
user_srtp1!: on
user_srtp2!: on
user_symmetrical_rtp1!: off
user_symmetrical_rtp2!: off
user_server_type1!: asterisk
user_server_type2!: asterisk
user_savp1!: mandatory
user_savp2!: mandatory
empty_tls_client_cert!: off
xcap_via_tls!: true
tls_server_authentication!: on
user_auth_tag1!: off
user_auth_tag2!: off
support_rtcp!: off
On Aastra 6757iCT I got TLS working, and SRTP for inbound. Unfortunately, when SRTP is active, dialing out doesn't work at all, with "call failed" every time so far. I've gone through most of the DTMF options, inluding SIP, and still no joy. The difference between CA certs and Trusted Certs on the TLS support page is not clear to me. Aastra says to put your CA root & intermediate certs in CA Certs and Trusted Certs on the TLS support menu. For my mode -- persistent TLS -- I have only trusted certificates, a PEM file with concatenated public certs of my Asterisk server and its issuing CA.) Also, you need to manually set all the ports to 5061 for TLS. The others phones switched ports automatically. Relevant lines:
sip local port: 5061
sip local tls port: 5061
sip proxy port: 5061
sip registrar port: 5061
sip outbound proxy port: 5061
sip srtp mode: 0
(SRTP disabled -- so dialing out can work.)
sip transport protocol: 4
sips trusted certificates: asterisk2.pem
sips persistent tls: 1
I'd like to make more progress on the Aastra, but it requires even more reboots than the Snom.
Finally, run Cain again to see if your phones are encrypted for SIP and Voice. Even when SRTP is encrypting voice traffic, you can tell that a call is happening and how log it lasts. If you can't get a tap, you can do a TCP dump to a .cap file on your Asterisk server and then open it with Wireshark. Then you can take a look to see if the data looks encrypted.
Leftover vulnerabilities: This configuration still uses passwords for client authentication. You can use client-side certs if you want. Certificate Authorities are vulnerable. Bria (at least on Windows) uses the Windows Certificate Authorities that come installed. SNOM phones ship with CA certs aboard. (You still have to upload your own certs to the SNOM phone.) SNOM has no mechanisms for a certificate revocation list, so compromised CAs can be used to impersonate your certificates in a MITM attack. Aastra makes you upload any CA certs for trust.
Finally, for the SNOM phones that have the OpenVPN client, using the OpenVPN connection back to your Asterisk server and encryption within the (encrypted) VPN connection should provide some additional level of security.
(Assuming you haven't left your private keys exposed someplace.)
The secure PBX is not connected to the PSTN. And when you say man-in-the-middle attack, think government-in-the-middle. It's gender neutral.
To get encryption running in Asterisk, take things step by step. Asterisk encryption is really two types of enrcryption: SIP-S, or SIP over TLS for signalling -- traditional PKI using OpenSSL; and SRTP for the voice traffic. Each is configured independently under each extension. Asterisk Encryption is not end-to-end. It is extension-to-Asterisk, and maybe Asterisk-to-Asterisk on trunks. Asterisk encryption is not foolproof, and it will not encrypt calls to the PSTN. It's still vulnerable to MITM attacks with faked certs, and to a compromise of your Asterisk install. Also, just because your connection to Asterisk is encrypted and the lock symbol shows up on your phone doesn't mean the other extension (or trunk) on the other side of Asterisk is also secure.
The key for SRTP is exchanged over the SIP channel, so if SIP's not encrypted, what's the point of bothering with SRTP? If you want to see what you're missing by not using encryption, download Cain from oxid.it and run it while you register the Bria softphone client and make a call from your windows computer. You get hashes of your SIP passwords and recordings of your phone calls, all from a GUI Windows program. If you have a network tap or span port in the right spot, you can intercept every call and signal between your Asterisk server and its SIP endpoints.
To get started, Asterisk 1.8 requires libsrtp. (You can thank Cisco for making it available, too.) You'll need to download, configure, make, make runtest, and make install before you hit ./configure on your Asterisk source. (Yes, recompiling Asterisk is necessary.) Then, when you do ./configure on your Asterisk source, you'll get an error when it finally gets to checking your libsrtp availability. Google the error phrase, and you'll learn what to change in the CFLAGS line of your libsrtp Makefile. Recompile and reinstall libsrtp, then reconfigure Asterisk. Then in your Asterisk source, make menuselect and select libsrtp under resources. Don't forget to make sure your other cool Asterisk features (like gtalk) are still enabled before you save and exit. Then recompile and reinstall Asterisk. There are plenty of tutorials for these steps on the Interwebs.
Once Asterisk is running again, you can start by getting a certificate for TLS. I am not going to do yet another certificate from self-signed CA howto here. There's an excellent one over at madboa. It's nice for Asterisk to now include a CA/Cert script, but you should really understand how SSL works. I know people who send private keys via email.
Another note about certificates: even if all your workstations are in a friendly LAN with the same DNS suffix, use the fully-qualified Domain Name (FQDN) for your Asterisk certificate. Some endpoints (Bria, I'm looking at you) require FQDN and cannot validate the certificate if you're getting to your Asterisk server by a short name. Using IP addresses for the registrar in your endpoints? That won't work either. You'll need the CA cert on some endpoints but not others. (Snom phones like certs in DER format; Asterisk and Aastra like PEM. To copy from PEM to DER, try this:
openssl x509 -in input.crt -inform PEM -out output.crt -outform DER
Once you get your CA and certificate, your sip_general_custom.conf file should have lines as follows. (In FreePBX, sip_general_custom.conf is the one you can hand-edit safely.)
tcpenable=yes ; If you don't have TCP enabled for SIP now, go ahead and enter this and test it.
tlsenable=yes
tlsbindaddr=0.0.0.0
tlsclientmethod=tlsv1
tlscertfile=/etc/asterisk/keys/asterisk.crt ; concatenate the key file to the bottom of the cert file so they're together.
tlscafile=/etc/asterisk/keys/asteriskCA.crt
tlscipher=AES256-SHA:AES128-SHA:RC4-SHA:RC4-MD5;
Some say put "ANY" there for tlscipher. I suggest you want encryption that's strong but compatible with your endpoints. For valid strings, look here: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS. To see which one your endpoint is using, you'll need to do a network capture via Wireshark. If there's no shared cipher between your endpoint and Asterisk, you'll see something like this in your logs:
/var/log/asterisk/full:[2012-01-03 13:59:30] VERBOSE[29926] tcptls.c: == Problem setting up ssl connection:
error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
Also, you'll need to trust your self-signed CA in Linux. (Seriously, don't set tlsdontverifyserver=yes -- it's just lame.)
If you're on Fedora or CentOS, the folder is /etc/pki/tls/certs.
# ln -s myAsteriskCA.cer `openssl x509 -hash -noout -in myAsteriskCA.cer`.0
then verify:
# openssl verify -CApath /etc/pki/tls/certs /etc/asterisk/keys/myAsterisk.cer
should get you a:
/etc/asterisk/keys/myAsterisk.cer: OK
Once you have a certificate in place, restart Asterisk and see what comes up:
/var/log/asterisk/full:[2012-01-02 23:37:26] VERBOSE[24700] tcptls.c: SSL certificate ok
Then you can try connecting with TLS. In FreePBX, you go to the particular extension you want to test and select TLS Only and reload. Each endpoint is different. Once TLS is successful, you can try setting the extension to use SRTP encryption in FreePBX.
Notes on Phones:
Each phone is different. Bria was easy, so you may want to start with that to see if Asterisk is working correctly. In account settings, domain needs to be a FQDN that matches what you've assigned the certificate. You also need to import the your CA cert into Windows' CA certificate store. For signaling transport, select TLS. For SRTP, select "Make and accept only encrypted calls" for Media Encryption. With any luck, when you hit the apply button, you should see "All accounts are active." While Bria for Windows validates certificates, it's optional on the Bria for iPhone/iPad.
The other software phone, 3CX, has settings for TLS but gets caught in an SSL handshake loop when trying to register, in spite of a shared cipher suite.
For the SNOM 370 to connect via SRTP successfully, I had to set RTP/SAVP to Mandatory. (Identity | RTP in the Snom Menu.) If you have multiple SIP accounts to the same Asterisk server in your SNOM phone, having any one ID configuration incorrect can break them all (Error message "Not acceptable here" whenever you dial). Also set the SRTP Key to 80-bit; 32-bit is the SNOM default, which doesn't work. (This has changed in Asterisk 10: Add option encryption_taglen to set auth taglen only 32 and 80 are supported currently.)
Also, disable RTCP support in SNOM if you don't want Asterisk to crash when it's doing SRTP.
user_host1!: my.asterisk.net;transport=tls
user_host2!: my.asterisk.net;transport=tls
user_srtp1!: on
user_srtp2!: on
user_symmetrical_rtp1!: off
user_symmetrical_rtp2!: off
user_server_type1!: asterisk
user_server_type2!: asterisk
user_savp1!: mandatory
user_savp2!: mandatory
empty_tls_client_cert!: off
xcap_via_tls!: true
tls_server_authentication!: on
user_auth_tag1!: off
user_auth_tag2!: off
support_rtcp!: off
On Aastra 6757iCT I got TLS working, and SRTP for inbound. Unfortunately, when SRTP is active, dialing out doesn't work at all, with "call failed" every time so far. I've gone through most of the DTMF options, inluding SIP, and still no joy. The difference between CA certs and Trusted Certs on the TLS support page is not clear to me. Aastra says to put your CA root & intermediate certs in CA Certs and Trusted Certs on the TLS support menu. For my mode -- persistent TLS -- I have only trusted certificates, a PEM file with concatenated public certs of my Asterisk server and its issuing CA.) Also, you need to manually set all the ports to 5061 for TLS. The others phones switched ports automatically. Relevant lines:
sip local port: 5061
sip local tls port: 5061
sip proxy port: 5061
sip registrar port: 5061
sip outbound proxy port: 5061
sip srtp mode: 0
(SRTP disabled -- so dialing out can work.)
sip transport protocol: 4
sips trusted certificates: asterisk2.pem
sips persistent tls: 1
I'd like to make more progress on the Aastra, but it requires even more reboots than the Snom.
Finally, run Cain again to see if your phones are encrypted for SIP and Voice. Even when SRTP is encrypting voice traffic, you can tell that a call is happening and how log it lasts. If you can't get a tap, you can do a TCP dump to a .cap file on your Asterisk server and then open it with Wireshark. Then you can take a look to see if the data looks encrypted.
Leftover vulnerabilities: This configuration still uses passwords for client authentication. You can use client-side certs if you want. Certificate Authorities are vulnerable. Bria (at least on Windows) uses the Windows Certificate Authorities that come installed. SNOM phones ship with CA certs aboard. (You still have to upload your own certs to the SNOM phone.) SNOM has no mechanisms for a certificate revocation list, so compromised CAs can be used to impersonate your certificates in a MITM attack. Aastra makes you upload any CA certs for trust.
Finally, for the SNOM phones that have the OpenVPN client, using the OpenVPN connection back to your Asterisk server and encryption within the (encrypted) VPN connection should provide some additional level of security.
(Assuming you haven't left your private keys exposed someplace.)
The secure PBX is not connected to the PSTN. And when you say man-in-the-middle attack, think government-in-the-middle. It's gender neutral.
Friday, March 20, 2009
Why the telemarketers aren't stopping.
June 16, 2009 update: Fox News has a story on the auto-warranty Scammers.
With the implementation of the National Do-Not-Call registry, you'd think that telemarketing activity would decrease. Instead, telemarketing activity is increasing. Of course, it's impossible to measure, because there are no reliable statistics for illegitimate telemarketing activity. By illegitimate, I mean not just that they're not supposed to call you, but they're trying to scam you with a bogus auto warranty, fake sweepstakes winnings, or fake identity-theft protection services.
The cost of calling has dropped dramatically. With SIP trunking and the g729 codec, I can squeeze a hundred calls across a T1. The SIP trunk will cost me $.01 per call-minute. An open-source PBX will cost a few hundred dollars for server hardware. Robocalling and autodialing scripts are free. Add in a kilobuck hardware codec card, and I can start calling every number there is. A thousand sixty second robocalls cost me $10.00 and take only ten minutes to complete at a hundred concurrent calls a minute. My caller ID is whatever I enter into the caller id field. Faking caller id is trivial and legal. Even if only one in a thousand calls hooks me up to a sucker, I'm making money.
If I'm a telescammer, I'm not really concerned with the do not call list. If I'm faking my ID, what are you going to do -- report a number? A company that doesn't exist? I'm practically untraceable. If you *69 me, all you get is the faked caller ID number. You'd need a trap-and-trace from your phone company, and you can't do that without a threat. Even if you do get one, I've already called. I'm not going to call again, and if I do, it'll be from a different number. In Canada, the do-not-call list is a service for scammers to get Canadian phone numbers.
The economics make it almost as cheap as spam, and spam is a LOT easier to block than roboscammers. Blacklisting phone numbers, or even faked caller-id numbers is not easy. There are several free web services tracking this type of information, like whocalled.us and 800notes.com. However, there's no update service to add this to phone blocklists, which don't exist. Vonage won't let you blacklist numbers unless you get their Wifi hardware phone. Even Verizon's anonymous call blocking permits obviously bad 000-000-0000 numbers through.
Freepbx has a great blacklist, but it blacklists only known bad numbers. What we really need is a shared database of bad originating numbers.
With the implementation of the National Do-Not-Call registry, you'd think that telemarketing activity would decrease. Instead, telemarketing activity is increasing. Of course, it's impossible to measure, because there are no reliable statistics for illegitimate telemarketing activity. By illegitimate, I mean not just that they're not supposed to call you, but they're trying to scam you with a bogus auto warranty, fake sweepstakes winnings, or fake identity-theft protection services.
The cost of calling has dropped dramatically. With SIP trunking and the g729 codec, I can squeeze a hundred calls across a T1. The SIP trunk will cost me $.01 per call-minute. An open-source PBX will cost a few hundred dollars for server hardware. Robocalling and autodialing scripts are free. Add in a kilobuck hardware codec card, and I can start calling every number there is. A thousand sixty second robocalls cost me $10.00 and take only ten minutes to complete at a hundred concurrent calls a minute. My caller ID is whatever I enter into the caller id field. Faking caller id is trivial and legal. Even if only one in a thousand calls hooks me up to a sucker, I'm making money.
If I'm a telescammer, I'm not really concerned with the do not call list. If I'm faking my ID, what are you going to do -- report a number? A company that doesn't exist? I'm practically untraceable. If you *69 me, all you get is the faked caller ID number. You'd need a trap-and-trace from your phone company, and you can't do that without a threat. Even if you do get one, I've already called. I'm not going to call again, and if I do, it'll be from a different number. In Canada, the do-not-call list is a service for scammers to get Canadian phone numbers.
The economics make it almost as cheap as spam, and spam is a LOT easier to block than roboscammers. Blacklisting phone numbers, or even faked caller-id numbers is not easy. There are several free web services tracking this type of information, like whocalled.us and 800notes.com. However, there's no update service to add this to phone blocklists, which don't exist. Vonage won't let you blacklist numbers unless you get their Wifi hardware phone. Even Verizon's anonymous call blocking permits obviously bad 000-000-0000 numbers through.
Freepbx has a great blacklist, but it blacklists only known bad numbers. What we really need is a shared database of bad originating numbers.
Monday, December 1, 2008
Free 411 Service with Asterisk
Google has launched a free 411-style information service. It's not the first free one, by any means, but since it's Google's, I'll have higher expectations about its usability. There's another one available -- that's even older than Google's service. It's too bad you have to pay for e911 service, because doing the same won't send your name and address to your local PSAP.
The catch is, when you're dialing for information, you're at the phone, not the computer, and you may not have memorized the number. (1-800-GOOG-411.) If you're running Asterisk, you can easily reprogram 411 to go to the free 411 service of your choice. Just add the following lines to your extensions_custom.conf in /etc/asterisk:
[from-internal-custom]
exten => 411,1,Answer
exten => 411,2,Dial(SIP/mytrunkname/18004664411|300|)
exten => 411,4,Hangup
The catch is, when you're dialing for information, you're at the phone, not the computer, and you may not have memorized the number. (1-800-GOOG-411.) If you're running Asterisk, you can easily reprogram 411 to go to the free 411 service of your choice. Just add the following lines to your extensions_custom.conf in /etc/asterisk:
[from-internal-custom]
exten => 411,1,Answer
exten => 411,2,Dial(SIP/mytrunkname/18004664411|300|)
exten => 411,4,Hangup
Subscribe to:
Posts (Atom)