VoIP calls – like all  network traffic – can be listened to by potentially malicious people. However voice calls are probably in greater need than other network traffic because it tends to be more personal. People have grown to trust phones as the best alternative to face to face correspondence for privacy. People would not be happy knowing that a third party could record their conversation and play it back at a later time.  However, not all voice traffic needs encrypting – after all the chances of a malicious user on an internal network is very low.

Even though the SIP side of Asterisk does not have much security the IAX protocol does have encryption support. However this message on the digium mailing list raises some issues as to the actual security of the implementation.

For our purposes we chose to tunnel the calls through a VPN. OpenVPN is a very easy to use VPN software system. We set it up so that clients can create the tunnel to our external Asterisk system. We also decided to tunnel the trunk between the internal and external systems over the VPN.

There are third party (and internal efforts) implementations of VoIP security for Asterisk in various stages of completeness, but for now we have decided to go with a system that is more mature and trusted. Hopefully in the future Asterisk will have better support for this included as standard.

http://www.bpvn.com/asterisk/iaxping.zip

To create the trunks, I first looked at how they are typically implemented. A good example can be seen here. Basically, the most popular way to set up a trunk involves the following.

1. Create a friend account on serverA in iax.conf
   
[general]
register =><username>:<password>@<serverB hostname or IP>
[serverB]
type=friend
user=<username>
secret=<password>
host=<serverB>

   extensions.conf
   
exten => _7XXX,1,Dial(IAX2/serverB/${EXTEN:1},30,r)
exten => _7XXX,2,Congestion

2. Create a friend account on serverA in iax.conf.
   
[serverA]
type=friend
user=<username>
secret=<password>
host=<dynamic> | <serverA>

   extensions.conf
   
exten => _7XXX,1,Dial(IAX2/serverA/${EXTEN:1},30,r)
exten => _7XXX,2,Congestion


However, I noticed one problem straight away with translating something like this to Realtime. I wouldn’t be able to get the register => statement into a Realtime row in the database.

Back to the drawing board. There was another suggested way of creating a trunk. The register => statement is used in a case where the the hostname/IP of one of the friends is unknown. In my case, I knew both and they wouldn’t be changing (even in production) after they’d been set. So by setting the host fields on the friend sections of both, I could keep the register => statement out.

But this left one other issue. When making outgoing calls, the Dial() application now requires the password and host to be added. The only issue with this is that the password will be included in CDR records. But this won’t be an issue for the application in question.

Anyway, I hope you find this useful. Its a solution made from a collection of other solutions so I’ll probably be updating it further as I go.Feel free to post feedback in the comments section below.

Until today I used the simplest way to ring a user, when a call comes in for a user ring both boxes at the same time. Asterisk will bridge the call to the first channel that picks up, which works. However today I was perusing some of the documentation and came across a SIP realtime database field – regserver.

You need to set a couple of things for this to work.

1. Have a systemname => whatever in asterisk.conf under [options]
2. Set rtsavesysname=yes in sip.conf under [general]
3. Have a column called “regserver” in the SIP peer database

If these conditions are met then when a user registers on a given Asterisk box then the regserver field will be set to the systemname value in asterisk.conf. Using this, it would be simple enough to write a func_odbc function that figures out where the user is and which Asterisk server to call them through. When I have time I will actually implement this and post any dial-plan logic needed to get it working. I have yet to find any built-in Asterisk way of doing the query rather than relying on func_odbc, if I find something I will post information on it instead.

The Asterisk PBX guide is the new Asterisk Book currently being sold by Amazon in the states. After going through most of the book in detail Ive finally got around to reviewing it. Comments as follows ::

• The book starts of with an introduction into Asterisk 1.4 including a complete step buy step guide on how to configure Asterisk from the ground up .. excellent for newbies
• If anybody has taken the Asterisk Bootcamp course, this book will seem particularly familiar at first glance …. however, its quite detailed in parts and even for the experienced Asterisk user will answer some of those ” ahh thats what its for ” questions.
• For Asterisk Newbies the book turns out a bit stronger than the O’Reily book ( although the 2nd edition of this is coming out soon )
• The physical quality of the book (paper) is quite poor and the 370 pages probably an actual 250 due to the excessive large font type used. There are also a number of mistakes and grammatical errors.

Overall for the beginner this is probably the best book on the market at present explaining most of the core applications that Asterisk is capable of. However, for experienced asterisk users wait for the “Asterisk Cookbook”

One of the biggest differences between extensions.conf and Asterisk’s Realtime dial plan is that one can no longer include other contexts into another context. This is the classic way of building an tiered dialling rule hierarchy, create the most restrictive context, then use ‘include’ to add more and more allowed numbers. E.g:

[emergency]
exten => 112,n,Dial(IAX/PSTN/112)

[local]
include => emergency
exten => _051.,n,Dial(IAX/PSTN/${EXTEN})

[national]
include => local
exten => _0[1-79].,n,Dial(IAX/PSTN/${EXTEN})

[mobile]
include => national
; etc for mobile, international and high rate numbers

If we wanted to store this in a database we have a few options.

• We could copy all the extension logic in each context. Not really nice nor maintainable at all.
• We could hard code the includes into extensions.conf before switching to realtime. I haven’t tried this, but maybe it would work. However it is unsuitable for our purposes because we want to make a PBX the customer can configure online, so if they try to add additional contexts then this will break. We want as close to 0 reloading as possible. Customers will share PBXs so there will be unique contexts created for each customer.

A workaround for the moment is to bypass Asterisk’s routing and lump all the users into the same context initially. This context will use some func_odbc magic dust to route users into the appropriate context. I created a table like so (text based key for illustrative purposes, you could use a numeric id instead if you like)

In the table the regex matches up with the context so that if you match the first regex your call will be routed to the first context. This is because func_odbc doesn’t seem to handle returning multiple rows at a time. There are ways to reduce the amount of repetition (chaining of ids to create “linked lists” of regex/context pairs perhaps) but for our purposes we are only experimenting in ways to get around these Asterisk limitations.

This way our dial plan is simple. Everyone shares the same context. This context reads the users permission id from the users account (all our SIP accounts are also stored in the database). We then read the regex and contexts from this table and loop to find a match. When a match is found, the user is placed in the correct context.

[routing_context]
exten => _[0-9a-z].,1,Set( permission=${ODBC_GETPERMISSION_BYCID(${CALLERID(all)
})})
exten => _[0-9a-z].,n,Set( tmp="${ODBC_GETREGEX_CONTEXT_BYPERMISSION(${permissio
n})}")
exten => _[0-9a-z].,n,Set(fullregexp="${CUT(tmp,\,,1)}")
exten => _[0-9a-z].,n,Set(context="${CUT(tmp,\,,2)}")
exten => _[0-9a-z].,n,Set(i=1)
exten => _[0-9a-z].,n,While(1)
exten => _[0-9a-z].,n,Set(regexp="${CUT(fullregexp, ,${i})}")
exten => _[0-9a-z].,n,ExecIf($["${regexp}" = ""]|Hangup)
exten => _[0-9a-z].,n,ExecIf( $[${REGEX("^(${regexp})" ${EXTEN})}]|Goto|${CUT(co
ntext, ,${i})}|${EXTEN}|1)
exten => _[0-9a-z].,n,Set(i=$[${i} + 1])
exten => _[0-9a-z].,n,EndWhile()
exten => _[0-9a-z].,n,Hangup()

It is a pity that there doesn’t seem to be an easier way to add contexts to the database without needing to change extensions.conf. However this way we can, however ugly the dial plan in extensions.conf needs to be.

Linphone on Linux works, at least when you have a Quad A DNS record for your registrar. However, I could not seem to use a raw IPv6 address as a registrar address. The other Linux offering was “Kphone”, but I found that it’s IPv6 support was a minor branch last updated in 2004, so when I finally got it compiled it segfaulted instantly.

A Java client I found, “SIP-communicator”, works OK on Windows. Using the default Debian package provided it installs under Linux but doesn’t seem to run.

Finally “AGEphone”. It isn’t great, as it’s free version only support calls or up to 1 minute, but it suffices for testing.

I’ll assume you have a working and tested Asterisk installation with a Asterisk Realtime ODBC connection for one or more configuration files (in my case, sip.conf got the Realtime treatment). My res_odbc.conf looks something like this:

[asterisk]
enabled => yes
dsn => dbserverdsn
username => username
password => password
pre-connect => yes


Next I set up the queries that I want to run from the dial plan

[VOTESFORCANDIDATE]
dsn=asterisk
read=select votes from poll where candidate_id = '${SQL_ESC(${ARG1})}'
write=update poll set votes = votes + 1 where candidate_id = '${SQL_ESC(${ARG1})}'

This is a fairly contrived example where there’s a table called poll with the ids of candidates and and a count of votes for each candidate. One of the key characteristics of func_odbc is that the functions are like property get/set methods from other languages. Setting the value of a variable to the result of the function executes the ‘read’ procedure whereas setting the value of the function executes the ‘write’ procedure. You’ll get a better idea from the example dial plan below.

[default]
; dial a number for the candidate (e.g. 901) to vote for them
exten => _9XX,1,Answer()
exten => _9XX,n,Set(${ODBC_VOTEFORCANDIDATE(${EXTEN})})
; responds with the total votes
exten => _9XX,n,Set(votes=${ODBC_VOTEFORCANDIDATE(${EXTEN})})
exten => _9XX,n,SayNumber(${votes})
exten => _9XX,n,HangUp()

So there you have it…anything from the General Election to ‘Pop Idol’ can run on this now (but not securely).

Much more difficult was the location of a suitable client to test it with. Read Niall’s entry to find out more about Counterpath’s “offering”, but I found an Asian client that worked quite well, “Spiderphone“. I tried a windows port of “Linphone”, but it failed to register properly. It must be noted that the windows port is behind the Linux version, so it possibly works much better there. Other Linux based phones such as “Kphone” also claimed IPv6 support but I could find any windows version of them.

A significant portion of Asterisk’s code SIP base is dedicated to overcoming the problems of SIP with NAT, I would estimate. This kind of problem would disappear with IPv6. But right now there is kind of a chicken and egg situation regarding VoIPv6, there is little in the way of an IPv6 SIP infrastructure and few clients. Hopefully when IPv6 support gets enabled in Asterisk’s trunk code base half that problem will no longer apply and more client programs will be moved to IPv6.

We decide to purchase some eyebeam clients ( the paid version of X-Lite) to test out on the system. On the Counterpath website they clearly state that EyeBeam has IPv6/AAAA support – See attached Image. However, this is not the case. They require you to purchase large amount of licences to get IPv6 support for eyebeam claiming that your only purchasing their “retail” version. Clearly their website dosent state this case. The search is back on for an IPv6 user agent that works!!

A perfect world — > End to End Voip calls………