SIP - One Way Audio

In SIP if you work with Nat, Firewall, some time you will be facing one way audio, for which you need to open some ports in firewall. TCP port 5060 and UDP ports 5000 to 31000. Apart from this you can also enable stun server if you face still one way audio. More information click here...

Seven Steps to Better SIP Security with Asterisk

In case any of you were wondering why there has been a fairly notable upswing in the attacks happening on SIP endpoints, the answer is “script kiddies.” In the last few months, a number of new tools have made it easy for knuckle-draggers to attack and defraud SIP endpoints, Asterisk-based systems included. There are easily-available tools that scan networks looking for SIP hosts, and then scan hosts looking for valid extensions, and then scan valid extensions looking for passwords. You can take steps, NOW, to eliminate many of these problems. I think the community is interested in coming up with an integrated Asterisk-based solution that is much wider in scope for dynamic protection (community-shared blacklists is the current thinking) but that doesn’t mean you should wait for some new tool to defend your systems. You can IMMEDIATELY take fairly common-sense measures to protect your Asterisk server from the bulk of the scans and attacks that are on the increase. The methods and tools for protection already exists – just apply them, and you’ll be able to sleep more soundly at night.

Seven Easy Steps to Better SIP Security on Asterisk:

1. Don’t accept SIP authentication requests from all IP addresses. Use the “permit=” and “deny=” lines in sip.conf to only allow a reasonable subset of IP addresess to reach each listed extension/user in your sip.conf file. Even if you accept inbound calls from “anywhere” (via [default]) don’t let those users reach authenticated elements!
2. Set “alwaysauthreject=yes” in your sip.conf file. This option has been around for a while (since 1.2?) but the default is “no”, which allows extension information leakage. Setting this to “yes” will reject bad authentication requests on valid usernames with the same rejection information as with invalid usernames, denying remote attackers the ability to detect existing extensions with brute-force guessing attacks.
3. Use STRONG passwords for SIP entities. This is probably the most important step you can take. Don’t just concatenate two words together and suffix it with “1″ – if you’ve seen how sophisticated the tools are that guess passwords, you’d understand that trivial obfuscation like that is a minor hinderance to a modern CPU. Use symbols, numbers, and a mix of upper and lowercase letters at least 12 digits long.
4. Block your AMI manager ports. Use “permit=” and “deny=” lines in manager.conf to reduce inbound connections to known hosts only. Use strong passwords here, again at least 12 characters with a complex mix of symbols, numbers, and letters.
5. Allow only one or two calls at a time per SIP entity, where possible. At the worst, limiting your exposure to toll fraud is a wise thing to do. This also limits your exposure when legitimate password holders on your system lose control of their passphrase – writing it on the bottom of the SIP phone, for instance, which I’ve seen.
6. Make your SIP usernames different than your extensions. While it is convenient to have extension “1234″ map to SIP entry “1234″ which is also SIP user “1234″, this is an easy target for attackers to guess SIP authentication names. Use the MAC address of the device, or some sort of combination of a common phrase + extension MD5 hash (example: from a shell prompt, try “md5 -s ThePassword5000″)
7. Ensure your [default] context is secure. Don’t allow unauthenticated callers to reach any contexts that allow toll calls. Permit only a limited number of active calls through your default context (use the “GROUP” function as a counter.) Prohibit unauthenticated calls entirely (if you don’t want them) by setting “allowguest=no” in the [general] part of sip.conf.

Opening Up with Google

Although Google is the most popular Web-based search engine used by everybody, not many know that it’s one of the biggest supporters of open source. For more on Google’s association with open source, here’s the story.

In January 1996, Larry Page and Sergey Brin, both students at Stanford University, began working on a search engine, which came to be called Google and took the world by storm. Initially, Page and Brin extensively used open source software such as Linux and GCC, internally. One of the reasons for using open source was, perhaps, the cost savings. However, the power that open source offered them—the ability to study and customise the source code to their preference—played a bigger role.

The creators of Google used free software wherever possible, even for corporate processes like accounting, record-keeping, etc. The use of free software for Google’s systems continues till date, with nearly all of its servers running on Linux. Page and Brin also used free software libraries such as OpenSSL, zlib, PCRE and MySQL. Since Google depended extensively on free software, its creators felt obliged to contribute to the various open source projects that had led to Google’s success.

If the software improves, everyone benefits, including Google. So, why keep the in-house fixes and improvements to the code a secret? Click Here for more....

A Quick List For VoIP Knowing | VoIP Websites

A Quick List For VoIP Knowing | VoIP Websites: "- Sent using Google Toolbar"

SIP Client for Blackberry

Callto.Net BlackBerry Vippie!