Not much to write about lately, but many of you, me included, use queue_log to generate important statistics about a company’s queue calls. It is important to see how many times a user have been called, how many times they answered, how long the calls last, etc.

But one thing missing, has been how many calls failed because of telephony failure, or configuration errors. So i’ve uploaded this:

https://issues.asterisk.org/view.php?id=16925

This patch makes app_queue more verbose to queue_log, reporting problems calling out, as well as marking them as “congestion” with a new parameter to the RINGNOANSWER queue_log entry. (also to the AMI event)

More information in the issue tracker.

A few years ago, I read this wiki page at voip-info.org, where I was informed of this nifty thing called TDMoE. TDMoE is TDM over Ethernet. This nifty DAHDI driver (dahdi_dynamic_eth), provides any dahdi signalling via Ethernet. So if you need to have PRI signalling between two asterisk servers in the same room. Look no further! Instead of buying expensive T1/E1 cards, to be able to talk PRI, you can just use your ethernet cards. TDMoE uses your network interface card to talk to the other asterisk box. To do this, both machines needs to know eachothers MAC addresses. Why? Because TDMoE uses it’s own ethernet type. Packets between the boxes goes through the ethernet via ethernet type 0xd00d. Inside the ethernet frame, lies a dahdi_dynamic packet, which in turn has the packet/frame from your chosen signalling standard.

But beware. You should have DAHDI compatible hardware in at least one of the asterisk boxes. This is because of timing, so you can use the timing from that card, to time the TDMoE. TDM packets needs to be sent every 1ms at a very stable rate. A normal computer without extra hardware cannot acheive 100% the correct timing requirements of DAHDI signalling protocols on it’s own. The kernel module dahdi_dummy (former ztdummy) can give you a signal close to ~99.4%(my results, testing with dahdi_test -v) of what the timing should be.

In my testing results, TDMoE works nice with dahdi_dummy, but I am unsure if this is stable over time. So better have some DAHDI hardware somewhere.

Before we start, I need to say that, by no means think that I am an expert at DAHDI or TDMoE, or that everything I write here is correct. I take no responsibility of what you do with the information on this post, or the correctness of the information here. If you see something that is plain wrong, please inform me, and I’ll update the post :)

So suddenly I came to the point where something like TDMoE would be very nice to have, and it worked like a charm. But on the ‘tutorials’ out there, almost all of them use the ’em’ signalling. So I thought I could write a bit of what you need to do, and what I did to get PRI signalling to work over ethernet with dahdi_dummy as timing source. So, to set up this, you first need to compile and install libpri, dahdi-kernel, and dahdi-tools on both machines. And then recompile asterisk, so they get dahdi and pri support.

After I did this, in my box with dahdi_dummy loaded I edited /etc/dahdi/system.conf and added the following:

dynamic=eth,eth1/00:00:01:00:00:00/0,31,0
echocanceller=mg2,1-15,17-31
bchan=1-15,17-31
dchan=16
alaw=1-15,17-31

Where 00:00:01:00:00:00 is replaced by the MAC address of the other server, and eth1 reflects the network interface I’d like to use for this. Then in /etc/asterisk/chan_dahdi.conf, I added the following:

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
facilityenable=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
immediate=no
 
switchtype=euroisdn
context=inbound
group=0
echocancel=yes
signalling=pri_net
channel =>1-15,17-31

Here you see I set the signalling type to ‘pri_net’, which means that this will be the network side of the pri signalling. Let’s call this the pri_net server. Then i configured dahdi by modprobing dahdi, modprobing dahdi_dummy, and running dahdi_cfg -vvv

If everything worked well, you should also be able to do dahdi_test -v, and see the precision to be close to 100%. You can now configure the other server. In /etc/dahdi/system.conf on this server, I had the same setup as the pri_net server, but here you put the MAC address of the pri_net server. So they point to eachother.

dynamic=eth,eth0/00:00:01:00:00:01/0,31,1
echocanceller=mg2,1-15,17-31
bchan=1-15,17-31
dchan=16
alaw=1-15,17-31

Remember to change the MAC adress.

Then in /etc/asterisk/chan_dahdi.conf on this server, I had:

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
facilityenable=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
immediate=no
 
switchtype=euroisdn
context=inbound
group=0
echocancel=yes
signalling=pri_cpe
channel =>1-15,17-31

Now here I set signalling to be pri_cpe, which means the customer side of the PRI line.

Now all you need to do is to modprobe dahdi, run dahdi_cfg -vv and hope for the best, and start asterisk.

If you type dahdi show status in asterisk, you should se a “OK” in the Alarms section, on your span. If you see RED, they don’t see eachother. Or if it’s Yellow, i think you have link, but the timing is not correct.

If you have problems with timing, you can check tcpdump -i eth0 ether proto 0xd00d, and you should see a buckload of packets flowing in. Also try to use the dahdi_test tool on both machines to compare timing. the pri_cpe machine will get the timing over ethernet, so it may be a bit off, if your network is not perfect.

I can now successfully make calls with DAHDI/g0/number with callerid etc. working spotless. :) Hope you can too!

[Update Jun 29, 2010: I’ve uploaded a TDMoE dissector patch for Wireshark]

Our mobile-phone operator has given us access to live status information about all the phones in our subscription. What this means is that when one of our phones are being called to, or turned of, or even roaming to another country; they automagically notifies us instantly via a private API.

What this means, is that we can make this information available to our existing phone system. Since we are using Asterisk, I was going to connect to AMI and update the device state of the mobile phone in question, when we received a status update via the API. The problem is. Asterisk didn’t have any AMI commands for updating Custom device states, only inside the dialplan. Luckily, it’s easy to add new commands to the AMI interface, and it was done in a jiffy.

If anyone is interested, the patch is up at https://issues.asterisk.org/view.php?id=16732.

Now, my Aastra 57i phone correctly lights up a red led, and shows a “un-hooked” icon in front of my extension on the expansion module on phone(or on the phone itself), when my mobile phone is in use.

This patch was developed because Asterisk was missing a ACD feature that our customer has on their previous IVR system. The feature is that if a person(read: agent) goes away from his/her phone, and forgets to log out from the queue, the agent gets ‘paused’ for a specific amount of ‘penalty’-time, where the agent won’t receive any more call attempts. This is almost like the “autopause” function, already present in Asterisk. Except that this one will unpause the user again after a given amount of time.

Lets say we have 3 agents in a queue.. The two first agents have priority 1, and the last one has priority 2. This means that as long as one of the first two agents are off their phones, the queue system will try to call those phones. It will not go to priority 2 unless both agents are busy on their phones, because, they’re free, right? With my patch, the two first agents are temporarily removed from the queue after they don’t answer before the timeout specified for the queue. Now the queue system will try agents in priority 2 automatically. This way, people who wait in line for an agent doesn’t have to wait for ages because one agent forgot to log off.

To accomplish this, I note the time when a member fails to answer his phone in time, and then neglects to call him anymore until (current time – no-answer time) is more than X seconds.

The amount of seconds to wait is defined in queues.conf with the new notpresent-penalty option, or in a realtime database, by a integer field with the name notpresent_penalty.

You can find the patch at Asterisks issue tracker

At work, I use Asterisk as the main system behind our IVR sollution. And sometimes we get into stuff that Asterisk just cant handle/do.

So I’ve started to peek a bit on the * source code, and started posting a few “quick fixes/mini features”.

Heres the list so far:

[manager] AMI Redirect: Posibility to send two channels in different direcitons
https://issues.asterisk.org/view.php?id=15853

[app_queue] Bugfix: app_queue segfaults if realtime field uniqueid is NULL
https://issues.asterisk.org/view.php?id=16385

[app_queue] Add support for ring indication when calling member
https://issues.asterisk.org/view.php?id=16384

All in trunk now :)

[Update: Now included in current Asterisk 1.8]