Knowledge Base

Gigaset Dect test mode

Setting test mode on the Gigaset handsets can be very useful. Detailed here is how to set a handset into test mode and what the numbers then mean. Once set go off on a walk round your site to find dead spots. Then change the base position to get the best coverage




The above screen Shows RX power at 100% , Frequency is 3 , TimeSlot is 02, Basestation code is 78 and finally Bit error rate is 100% (This means 100% Good not 100% error rate)

A short document on Setting test mode on Gigaset dect handsets for site surveys is available for download here. This shows you how to enable it and what each of the numbers mean.

Knowledge Base

Digium G100/200 Gateways and UK CallerID Number

The current firmware in the Digium G series gateways have a quirk that if they don’t receive caller ID name they move the caller Id number to be the Caller Id name but don’t leave the Caller Id number in place. The relies on you setting  “trustrpid=yes” in teh sip trunk configuration.

We have produced a short document on settings for using the gateway with any freePBX based asterisk solution. It can be downloaded here


Knowledge Base

Trusting Linux servers

This hopes to explain in simple steps setting up a pair (or more) servers as a trusted group.
So what do we want to achieve ? Well we wnat to be able to ssh, sftp, rsync etc between servers and not need to enter passwords
Steps required
1 Hosts File
2 Editing sshd_config
3 Create the ssh keys
4 Setting up the Auth. users file
Hosts File

Firstly we need to make sure all servers are in the hosts file
# Do not remove the following line, or various programs
# that require network functionality will fail. localhost asterisk2.local
# We point to eth0 on our own box asterisk2.local asterisk2
# We point to eth1 on the other box asterisk1

Editing sshd_config

Now we need to edit the /etc/ssh/sshd_config file
so that the following

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /root/.ssh/authorized_keys


#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

Now restart the sshd
/etc/init.d/sshd restart

Create the ssh keys

We now need to create the keys on each server
ssh-keygen -t rsa
and hit return for all the questions.
this will create 2 files in /root/.ssh

go the /root/.ssh directory and copy the to the other server and get its

sftp asterisk1


Setting up the Auth. users file

In the /root/.ssh directory you will now have for example :- id_rsa known_hosts

We now need to copy the to the authorized_keys file

cat >> authorized_keys

Do the same on the other server.

You should now be able to ssh and rsync between servers.

Knowledge Base

Sip debugging with wireshark

Wireshark and Cloudshark are invaluable tools for debugging sip and iax issues on your Asterisk server.

Here we have a short Video that goes over the basics of getting a call captured and opened in Cloudshark

we also have a short tutorial for download here in PDF format

First we need to get the packets we want. This is far simpler than its thought. We use a simple command line tool called tcpdump, if its not installed install it now, You wont be able to live without it.

Here we have 2 commands, The first captures packets on interface eth0, -n means we won’t convert addresses, -w means we just capture raw packets and udp means its only the udp packets we want and finally port 5060 means its only the sip messaging we want. In the second we dont specify port 5060 so that we get the rtp stream as well.

/usr/sbin/tcpdump -n -i eth0 -w /tmp/wireshark.pcap -s2000 udp port 5060
 /usr/sbin/tcpdump -n -i eth0 -w /tmp/wireshark.pcap -s2000 udp
screen -S "udpDump" -dm tcpdump -n -i eth0 -C 9 -W 15 -w /var/log/asterisk/dumpsip.pcap -s2000 udp port 5060

The command above will write to file in the background and will rotate at 9 meg so suitable for cloudshark

Once you have started the capture and made a call as required you will get a file called for example /tmp/wireshark.pcap copy this to your workstation via ftp or sftp as you would copy any file.

Asterisk Support Elastix Support Knowledge Base

Backing up to Amazon s3 from Elastix

We decided to do this as we have recently installed a new elastix server in the office which had limited disk space and wanted to keep offsite backups of recordings

s3cmd is a command line client for copying files to/from Amazon S3 (Simple Storage Service) and performing other related tasks, for instance creating and removing buckets, listing objects, etc.

Install s3cmd

 tar -xzvf s3cmd-1.1.0-beta3.tar.gz
 mkdir /usr/local/s3cmd/
 cd s3cmd-1.1.0-beta3
 cp -Rf * /usr/local/s3cmd/
 cd /usr/local/s3cmd/
 ./s3cmd --configure

Follow the prompts and enter your keys.

Test the installation
./s3cmd ls s3://yourbucket/

If the test works then the script below is a simple backup script to backup elastix monitor files and backups daily.

vi /etc/cron.daily/

 /usr/local/s3cmd/s3cmd --config=/some/where/.s3cfg sync /var/spool/asterisk/monitor s3://yourbucket
 /bin/rm -f /var/spool/asterisk/monitor/*.gsm
 /bin/rm -f /var/spool/asterisk/monitor/*.wav
 /usr/local/s3cmd/s3cmd --config=/some/where/.s3cfg ls s3://yourbucket/monitor/ > /var/log/s3dirlist.log
 /usr/local/s3cmd/s3cmd --config=/some/where/.s3cfg sync /var/www/backup s3://yourbucket
 /usr/local/s3cmd/s3cmd --config=/some/where/.s3cfg ls s3://yourbucket/backup/ >> /var/log/s3dirlist.log


enjoy :-)

For more details of what can be done with s3cmd see and


Knowledge Base

ISDN alarms and what they mean.

AIS (Alarm Indication Signal) CFA
The AIS is also known as a “Keep Alive” or “Blue Alarm” signal. This consists of an UNFRAMED all-ones signal sent to maintain transmission continuity. The AIS CFA signal is declared when both the AIS state and RED CFA persist simultaneously.

OOF (Out-Of-Frame) Condition

Occurs whenever Network or DTE equipment senses errors in the incoming framing pattern. Depending upon the equipment, this can occur when 2 of 4, 2 of 5, or 3 of 5 framing bits are in error. A reframe clears the OOF condition.
Red CFA (Carrier Failure Alarm)
Occurs after detection of CONTINUOUS OOF condition for 2.5 seconds. This alarm state is cleared when no OOF conditions occur for AT LEAST 1 second. Some applications (AT&T DACS services) may not clear the CFA state for UP TO 15 seconds of NO Out-Of-Frame occurrences.

Yellow CFA (Carrier Failure Alarm)

When a Terminal/Network equipment enters a RED CFA state, it transmits a “Yellow Alarm” in the opposite direction.
A Yellow Alarm is transmitted by setting Bit #2 of each timeslot to a 0 (zero), SPACE state for D4 Framed facilities. For ESF facilities, a Yellow Alarm is transmitted by sending a repetitive 16-bit pattern consisting of 8 MARKS (1) followed by 8 SPACES (0) in the Datalink bits. This is transmitted for a MINIMUM of 1 second.
LOS (Loss Of Signal)
A LOS condition is declared when no pulses have been detected in a 175 +/- 75 pulse window (100 to 250 bit times).

Notes taken from Digiums Realease notes

Alarm Types

An alarm indicates that a port is not available for some reason. Thus it is probably not a good idea to try to call out through it.

Red Alarm

Your T1/E1 port will go into red alarm when it cannot maintain synchronization with the remote switch. A red alarm typically indicates either a physical wiring problem, loss of connectivity, or a framing and/or line-coding mismatch with the remote switch.

When your T1/E1 port loses sync, it will transmit a yellow alarm to the remote switch to indicate that it’s having a problem receiving signal from the remote switch.

The easy way to remember this is that the R in red stands for “right here” and “receive”… indicating that we’re having a problem right here receiving the signal from the remote switch.

Yellow Alarm

(RAI — Remote Alarm Indication)

Your T1/E1 port will go into yellow alarm when it receives a signal from the remote switch that the port on that remote switch is in red alarm. This essentially means that the remote switch is not able to
maintain sync with you, or is not receiving your transmission.

The easy way to remember this is that the Y in yellow stands for “yonder”… indicating that the remote switch (over yonder) isn’t able to see what you’re sending.

Blue Alarm

(AIS — Alarm Indication Signal)

Your T1/E1 port will go into blue alarm when it receives all unframed 1s on all timeslots from the remote switch. This is a special signal to indicate that the remote switch is having problems with its
upstream connection. dahdi_tool and Asterisk don’t correctly indicate a blue alarm at this time. The easy way to remember this is that streams are blue, so a blue alarm indicates a problem upstream from
the switch you’re connected to.

Knowledge Base

Better SIP security

In Seven Steps

Original Text by J Todd March 28th, 2009

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.


These 7 basics will protect most people, but there are certainly other steps you can take that are more complex and reactive.  Here is a fail2ban recipe which might allow you to ban endpoints based on volume of requests.  There is discussion on the asterisk-user and asterisk-dev mailing lists of incorporating this type of functionality into Asterisk – let’s hear your ideas!


If you’d like to see an example of the tools that you’re up against, see this demo video of an automated attack tool that does scan, guess, and crack methods via a click-and-drool interface.
In summary: basic security measures will protect you against the vast majority of SIP-based brute-force attacks.  Most of the SIP attackers are fools with tools – they are opportunists who see an easy way to defraud people who have not considered the costs of insecure methods.  Asterisk has some methods to prevent the most obvious attacks from succeeding at the network level, but the most effective method of protection are the administrative issues of password robustness and username obscurity.


Asterisk Support Elastix Support Knowledge Base OpenVox

Asterisk pickup groups

The aim here is to explain the relationship between the callgroup and pickup group settings in extension conf files of an Asterisk server.

Call Pickup is the abilty to pickup a ringing phone from another phone.

The ability to do this is defined in the extensions conf file.

In many systems there is only on setting to do this normally “pickup group” you add etensions to this group and they can pickup calls ringing at members of the group. Obvious realy.

Now Asterisk goes one better. You can define the callgroup and pickup group, This way you define who you can pickup and who can pickup you. This is very useful for operators, who for example dont want calls picked up of them but do want to pickup calls from all other users.

So how do you define it.

In our example we will have 4 phones defined as follows

Callgroup Pickupgroup
201 2 1-2
202 1-4 1-4
203 2,4 2,4
204 1 1

And who can do what when trying t pickup is as follows

Ringing Phones attempting Pickup
Call to 201 204 PU failed 203 PU Passed
Call to 202 201 PU passed 203 PU Passed
Call to 203 201 PU passed 204 PU failed
Call to 204 201 PU passed 203 PU failed

So from this we can see that its the Pickupgroup that defines what callgroup can be picked up.

So because 201 has a callgroup of 2 Only sets whos pickup group includes 2 can pck up the call. whereas as 201 has a pickupgroup of 1-2 it can pickup calls from callgroups 1-2.

For example you may have 6 pickup groups defined with users only allowed to pickup their own group members except an operato who wishes to be able to pick everyone up and a PA who has a collegue who she wants to be able to pickup

So all normal users would have their pickup and callgroup the same. The PA would have the pickupgroup defined with both the group numbers but only its own call group. And finally the operator would have a callgroup of 0 and its pickupgroup of 1-6.

Numeric call pickup groups

A numeric callgroup and pickupgroup can be set to a comma separated list of ranges (e.g., 1-4) or numbers that can have a value of 0 to 63. There can be a maximum of 64 numeric groups. This is important to note as Freepbx does not sanity check what you put in there, So you can put 70 in the Gui and it will show 70 but do a sip show peer or a pjsip show endpoint and you will see its not set.

Named call pickup groups

Named pickup groups are new with Asterisk 11. But are not yet supported in FreePBX upto and including 13, So be carefull and dont add them to your pickup/call group settings yet in Freepbx as they will not work eventhough it shows in the GUI.

A named callgroup and pickupgroup can be set to a comma separated list of case sensitive name strings. The number of named groups is unlimited. The number of named groups you can specify at once is limited by the line length supported.

  • namedcallgroup – specifies which named pickup groups that this channel is a member.
  • namedpickupgroup – specifies which named pickup groups this channel can pickup.
Configuration Example

Configuration should be supported in several channel drivers, including:

  • chan_dahdi.conf
  • misdn.conf
  • sip.conf
  • pjsip.conf

pjsip.conf uses snake case:



You can use named pickup groups in parallel with numeric pickup groups. For example, the named pickup group ‘4’ is not the same as the numeric pickup group ‘4’.


Knowledge Base

Checking registered SIP peers

We got a call recently from a customer who uses skype trunks for some international incoming numbers. We have found that these lose registration on a regular basis, We could let them be set try and register indefinitely but this can have performance effects on the server.

This is not our only customer with this problem, We have also of late noticed a similar problem with Voip-unlimited where registration times out every day at 8pm, we have noted this on ours and other dealers servers.

So what to do?

Well we have written a quick script to check registration details and reload if not correct.


HITS=`asterisk -r -x “sip show registry” | grep Registered |grep $1| wc -l`

if [ $HITS != $2 ]; then

echo “Incorrect number of $1 trunks are registered, we wanted $2  ”

echo “We will now reload asterisk ”

asterisk -r -x “reload”

exit 0


echo “$HITS $1 trunks are registered, we wanted $2  ALL OK”

exit 0



the syntax for running the script is hostname 2

with hostname being part of the string you get when doing a sip show registry.

and the number is the number of registered trunks you expect with that name.

if all is well:”2 sipgate trunks are registered, we wanted 2 :-) ALL OK”and nothing happens

if not correct number then:

“Incorrect number of sipgate trunks are registered, we wanted 2

“We will now reload asterisk”

we only relaod the sip channel driver as this is enough to sort the problem normally

Knowledge Base Technical

Nagios plugin for reading the Asterisk Database

This is a simple plugin that is based on one by Jason Rivers We have changed it now to read the ASTDB (Asterisk internal Database and then based on ok and Critical keys it will report OK or Critical staus reports to Nagios.

This was written for reporting if an Elastix system is in Day or Night mode.

You can define the Database Family, Key, Critical value and OK value. This means you can cutomise it to what ever you need to report.


The Code is below, make you may need to change /usr/bin/nc for what ever you use for netcat.

any issues email us, but dont forget this is given for free not supported for free.

# Program : check_asterisk_ami
# :
# Author : Original code by Jason Rivers < >
# : Modified by for checking the asterisk Database
# :
# Purpose : Nagios plugin to return Information from an Asterisk host using AMI
# :
# Parameters : --help
# : --version
# :
# Returns : Standard Nagios status_* codes as defined in
# :
# Licence : GPL
# Notes : See --help for details
PROGNAME=`basename $0`
PROGPATH=`echo $0 | /bin/sed -e 's,[\/][^\/][^\/]*$,,'`
REVISION=`echo '$Revision: $' | sed -e 's/[^0-9.]//g'`
print_usage() {
echo "Usage: $PROGNAME [-H hostname] [-u username] [-p password] [-P port] [-k DBkey] [-c critical] [-o ok] [-f family]"
echo " -H Hostname"
echo " -u AMI Username"
echo " -p AMI Password"
echo " -P (optional) AMI PORT"
echo " -k Database key"
echo " -f Database family"
echo " -c Critical Key"
echo " -o OK KEY"
echo ""
echo "SupportedCommands:"
echo " Most DB familiys that toggle such as DayNight in elastix"
echo "Usage: $PROGNAME --help"
echo "Usage: $PROGNAME --version"
print_help() {
print_revision $PROGNAME $REVISION
echo ""
echo "Nagios Plugin to check Asterisk ASTDB using AMI"
echo ""
echo ""
echo "Asterisk Call Status Check. orignal version by © Jason Rivers 2011 changes to do ASTDB by"
echo ""
exit 0
# support
# If we have arguments, process them.
exitstatus=$STATE_WARNING #default
while test -n "$1"; do
case "$1" in
exit $STATE_OK
exit $STATE_OK
print_revision $PROGNAME $REVISION
exit $STATE_OK
print_revision $PROGNAME $REVISION
exit $STATE_OK
-u) AMIUSER=$2;
-p) AMIPASS=$2;
echo "Unknown argument: $1"
if [ "${AMIPORT}" = "" ]; then
if [ "${FAMIL}" = "" ]; then
echo="CRITICAL: Unknown KEY"
## Checking Astdb
CHANNELS=`/bin/echo -e "Action: login Username: ${AMIUSER} Secret: ${AMIPASS} Events: off Action: DBGet Family: ${FAMIL} Key: ${DBKEY} Action: Logoff " | /usr/bin/nc $REMOTEHOST ${AMIPORT} | awk '/Val/ {print $2}'|tr -d " "`
if [ "$CHANNELS" = "" ]; then
echo "UNKNOWN: Unable to get ASTDB status"
if [ "$CHANNELS" = "${OKNAME}" ]; then
MSG="OK: ${DBKEY} Asterisk Emergency message not active"
elif [ "$CHANNELS" = "" ]; then
MSG="WARNING: Asterisk Unknown status"
elif [ "$CHANNELS" = "$CRITICALNAME" ]; then
MSG="CRITICAL: ${DBKEY} Asterisk Emergency message active"
echo $MSG
exit $exitstatus