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.

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!

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.

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

For example, when you create a database, you fill inn the fields you like, in a ‘installer’. Each time you need to add fields, you add new up() revisions in the installer, so versioning systems like SVN or git can see that “in revision x, a new fields was added to the sql table”. This means that the versioning system can keep track of the database as well as the files.

Something I also love about Akelos is the ease of translation. In the Views you can write so called “sintags”. Which is basically the template language in Akelos. To write out the contents of a variable, you write {variable name} if you write text that needs translating, you write _{translate this text}. Thats variables and simple translations. Then you have functions, like a form:

<%= form_tag :id => 'myid' %>
<%= text_field 'blog', 'name', :class => 'myclass' %>
</form>

Now I wanted to be able to translate inside function tags, so I made a little adjustment to the Akelos source which made it possible to do:

 <%= link_to _'translated text', :action => 'about' %>
    or
 <%= something 'name', :vals => { 'plain text', _'translated text', _'translated text with %variable' } %>

Here you also see that translated text also can contain variables from the view scope, which is pretty nifty in regards to dynamic translating. This “adjustment” was added to trunk in October 2009.

The reason I did this, was because I used icecast, and had 5 streams up with a lot of users, but sometimes you would get sound from other streams on the same server, or old sound in the middle of the stream. I tried googling after other people with the same problems as me. But found nothing. So I thought; it’s quite simple software, how hard can it be to make a stable myself?

So first I made a proof-of-concept perl script to receive data, and send out to several listeners. Worked great at first try. Only a minior problems. If I paused the stream on one client, the whole server started waiting for that one listener, before sending any more data to all the other listeners. (more about this later) The other problem was that I didn’t have any in-stream “title” support.

The reason the stream stopped when one of the clients stopped listening for data (and blocked further data), is that I was sending data with a blocking socket. Now I tried googling about how to _send_ nonblocking, but coulnd’t find anything. So I made my own little workaround. (someone please give me a better solution)

Instead of:

$sock->syswrite($data)

I wrote a new send subroutine using IO::Select to check if the client is ready for data:

sub send {
	my $self = shift;
	my $sock = $self->{'sock'};
	my $data = shift;
 
	my $select = IO::Select->new;
	$select->add($sock);
	if ($select->can_write(0)) {
		return $sock->syswrite($data);
	} else {
		return 0;
	}
}

This finally did the work for me. The “send()” subroutine now returns how many bytes it sent to the client, and if it couldn’t send any, then it returns zero of course.

Then over to the problem of sending title updates inside the stream. I googled this and found a nice informative page about Shoutcast MetaData.  To bring it into a short explanation; if the client supports shoutcast metadata, it sends the following request header “Icy-MetaData:1” to inform the server that it knows about metadata. Then the server, my script, sends “icy-metaint: 123″ back in the response header, where “123″ is the amount of mp3 bytes before a metadata string should arrive. After exactly 123 (or whatever the server decides) bytes, the server sends a byte containing information about how long the metadata block is, and then the metadata right after. The “length byte” must be multiplied by 16 to get the real length of the metadata string. So the largest metadata string possible would be 4096 bytes long. Just after the metadata, the mp3 data continues as usual. Usually you won’t send the title data each time the metaint-counter goes around. You’re probably good by sending zero length metadata (just sending a ‘\0′ byte as metadata-length) all the time, until the title actually changes.

So at this time I rewrote the script, and mode it more module based, and added support for several streams, and yaml configuration file for access control, and some status pages, using TemplateToolkit.

So anyways, the script is still in early beta stage, but it should work fluently. It did however seem that the title-data got out of sync after about a day of listening to a stream, until you reconnected. Can’t seem to understand how it would get out of sync, unless a malformed tcp packet would arrive. So either I was testing it with a really crappy internet connection that time, or there is a bug berried deep in the simple code. You are free to have fun with the script, and tell me whats wrong. I also think it’s still full of debug printing. But I have already warned you, this is still in the proof of concept “whack-some-shit-together” stage. I’ts just one of those projects that ends up collecting dust.

If you fire the script up, and go to http://127.0.0.1:8001/ it should give you a list of the current connected streams. Also http://127.0.0.1:8001/xml should give you xml output of current streams. I’ve been using oddcast to send icecast stream to it.

Here’s the full script: perlcast.tar

We started for two days ago. William has a ENTTEC USB Pro which is fine for interfacing. In Linux, it is recognized as a standard COM port, and the API consists of sending characters to the virtual COM port.

So as an example of how easy it is to send DMX with this device from perl, I’ll give an example below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#!/usr/bin/perl
use Device::SerialPort;
use Time::HiRes qw/usleep/;
use strict;
 
my $PORT = '/dev/ttyUSB0';
 
my $ob = Device::SerialPort->new($PORT) or die "Can't Open $PORT: $!";
 
my $packet = chr(0) . (chr(128) x 30);
my $length = length $packet;
 
my $write = $ob->write("\x7E\x06" . chr($length & 0xFF) . chr(($length >> 8) & 0xFF) . $packet . "\xE7");
print "Wrote $write bytes to DMX controller\n";

This little script will send 30 channels of value 128 to the DMX controller, which will keep repeating this information, until it gets new information.

To clarify, the first byte 0×7E is the start byte for the enttec api. The next byte 0×06 is the function we are using, which is DMX OUT. Then there is two bytes of length information, describing how many channels we are going to send. And then the package is sent. It’s important to remember to send a 0×00 byte as the first channel, since this is the start byte of the actual DMX data. (also called the SC in the DMX standard specification)

We needed a central area to save our current channel data, and william found a nice perl module called Cache::FastMmap which uses mmap to save data. This way we can have several scripts using the same memory buffer, where we will putt the current DMX channel data. The first byte in the shared memory holds the current ‘version number’ of the data. Each time any data is changed, the first byte’s value is increased. This way each “reader” can check if there are new data asyncronically.

So after some initial successful testing, I created a module called Exploit::Scene. This is the module that all scripts that need direct DMX control will use. The external methods are pretty simple. You have get(), set(), to get and set a single channel value, isNew() and resetNew() to check if the DMX channel data has changed since last time you checked. commit() to save new channel data you have edited, and getDMXpacket() to get full 513 bytes of channel data. (or less, if you have set a smaller universe_size)

Now we could start to create some small test scripts. So William made a script that tests a single RGB LED fixture. And I created a console application to show/edit the DMX data. Of course these scripts are just for testing, and will not be used in the finished ‘product’, since everything will be centralized in a web interface to combine effects, etc.

Here you can se the console application i wrote with the Curses perl module. The green cursor on the left is moved with your up and down keys, to select a channel. If you use the left or right keys, you increase or decrease the channel value. If you press space, you toggle the channel to full 0xff or null 0×00 values. Page Up and Page Down will show you next ‘page’ of channels, up to 512. The color on the bars is reflecting the channel value, first 1/3 is red, next is yellow, and last is green. The console is live, so if any other processes is changing DMX data, it will immediately show the new data while you are editing. So it’s both a monitor and editor. Which will be nice to have when the full system is done. So we can monitor the dmx channels live without the actual fixtures.

We have created two backend scripts. backend-dmx and backend-udp. These connect to the mmap with the Exploit::Scene module as explained, and use the getDMXpacket() function to get the data to send to either the DMX controller, or udp. By UDP I mean that we are sending all the DMX data to a local multicast address. 239.255.0.$universe. This way, any computer on the network can connect to this stream, and get out the data it needs. So we can have several computers on the network triggering on DMX data. For this we have the Exploit::UDPScene module, which behaves similar to the MMAP version, but used multicast to get it’s data.

More info will come when we are further along with the project.