Gone for a while…

gone from blogging, but not from working ūüėČ

I’ll, eventually, explain these projects with more detail, but for now, I will just enumerate them so people can have a clue of what I’ve been working on:

1. cnxcc: this is a credit control module for Kamailio which deals with customers credit information to monitor the calls and hang them up if necessary.

2. cnxcc-db-sync: a php script to query the previous module (via xmlrpc) in order to feed a database with information coming directly from the module’s internal memory, really fresh and real time information.

3. cnxcc-web: a web based management interface for cnxcc.

4. webrtc + websockets: I’ve been reading a lot about this subject. I’ve even bought a book ūüėÄ

C# bindings for DWG2000 SMS API

Yes, it’s done and as I promised in my previous post, I am releasing it to the public.

This project started when a local company hired me to make the API support for Linux. It was a success and the sms-client started to work right away. It was not until 2 or 3 months after finishing the project that the idea of making the source code public came to my mind and despite this project may not be a great contribution to the community, it is the first of (hopefully) many.

This particular branch of the project might be specially useful for writing quick VAS software on top of the gateway. It is much easier to write business logic algorithms in C# than in C and in my case, that’s exactly what happened.

Get a copy from my github account

Dinstar SMS API client

I just committed the project that uses libdwgsms to send/receive text messages through Dinstar’s branded gateways.

The code goes as simple as follows, and you can check it from my github account:

Dinstar SMS API update

I’ve been working very hard in the past few months that updating my blog was relegated to the least of my priorities. It’s a pity, but I had no choice :(.

Back on the track, I came here to present an update of the Dinstar’s SMS API implementation which I started writing some time ago. I paused the project several times mostly because I had no economic reason to support my time on it , but luckily, the situation changed and today the great majority of the API is implemented and working.

I don’t maintain a changelog other than the one on github commit list, but basically, this is what changed:

– Support for API 1.4 and 2.0
– Support for authentication mechanism. (This is partial, check source code)
– Support for RSSI packages
– Support for Unicode strings
– The project is no longer a standalone application, now is a shared library.
– Several bug fixes

The C# bindings are also ready. I will publish the code probably next week.

Check the repo on github

Opensourcing my Clasipar bot

I’m opensourcing, after two years of continued use (:D), a bot for refreshing ads that were published in a specialized classified ads webpage called Clasipar, which is the most popular webpage for this kind of services here in Paraguay.

When you publish an advert on Clasipar, your announcement has a living period of 24 hours. After that, it gets lost among the thousands of other ads in the category it was published in. If you don’t periodically refresh your ad, in a daily basis for example, it will probably disappear completely¬†unnoticed and whatever business you wanted to do, will never be concreted.

This is where this bot comes in. Once your announcement is online, the bot refreshes it daily so you don’t have to worry about this task anymore. You can even publish 3 copies of the same¬†announcement and configure the bot to automatically refresh them at 9am, 1pm and 5pm, for example. This method allows you to get your ad always in the front page of its category.

On September¬†21¬†of 2010, I wrote a post about this piece of software and here’s the entry.

Check out the code at https://github.com/caruizdiaz/ClasiparBot. For usage, take a look to the README file.

Kamailio: shared memory hashtable

Using shared memory in Kamailio is fundamental and sometimes inevitable. Luckily, Kamailio’s core abstract us from A LOT of the complexity behind this kind of memory management and help us build a ready to use in-memory hash table in no time!

First of all, you need to include the str_hash header file but it is probably implicitly included by some other mandatory header files.

For this example, I’ll store the hashtable’s (HT from now on) address inside a global variable visible from the entire module. Being that the case, I need to create it as follows:

Later, I have to allocate some memory for the variable and there’s no better place for that than the module’s mod_init() function. Having allocated memory, I need to perform another allocation. This time is for the internal str_hash_table structure that contains the metadata for maintaining our information accessible. Usually, the function in charge of this task is str_hash_alloc() but looking its internals, we will find that it uses pkg_malloc() which certainly won’t work for us. Due this situation, I created an equivalent function for shared memory, mostly because Kamailio’s core doesn’t provide this functionality, or at least, I wasn’t able to find it.

Then, I need to define the structure that will be contained into the shared memory.

Storing and retrieving

In this example, I will store the call ID as the key of the HT’s entry and in the useful part, the call’s start and end timestamp.

First, I created a function that encapsulates all the logic for allocating a new call into shared memory. Please notice that having a HT storing your data, it doesn’t implicitly allocate your information in shared memory address space, this is, you have to allocate your structure using shm_malloc() before adding it to the HT.

Every entry in the HT is represented by str_hash_entry which is a linked-list ready structure that contains the key and the data part as an union. Take in consideration that an union is NOT an structure and its fields retain only one value at a time. Whatever modification you make to any field it will immediately affect to the others.

Finally we need a function callable from the script. In this case start_monitoring does this for us and it must be registered as an exported command.


To finish this little tutorial, I present the stop_monitoring which tries to retrieve the entry using the callid of the call. In case it was found, it writes the current timestamp to the field end_timestamp.

PS: I am aware that I never deallocated the memory I used. I may write the dealloc function for the next entry ūüėÄ

Visited by a famous

I’m talking about Carsten Bock, one the brightest minds behind the development of opensource VOIP projects. He came to Paraguay for business reasons and me and the guys here at Conexion had the pleasure of learning from him for almost two weeks. Not always we have the opportunity to hang out with such a great VOIP eminence around this part of the world so this situation deserves a blog post :D.

Reading pvars with Kamailio

It’s really hard to find documentation in some opensource projects, specially when you want to achieve something that’s not very common. I’m speaking about Kamailio project which is actually very well documented but its core development manual is not profound in topics that we may need to develop a fully functional module entirely in C. This post¬†pretends¬†to be the first of many short tutorials to¬†access to certain parts of the core dev API on which I wasn’t able to find any documentation or when it was present, it was not sufficient.

Reading system pvars.

This time is about reading pseudo variables like $rU, $si¬†or¬†$fU.¬†I won’t explain what pvars are because I’m assuming the reader has some basic knowledge but if you want to have ¬†a better understanding,¬†the development guide has a section dedicated to it but not with the approach I’m using here.

Ok, the code:

And finally, the way we should call it:

If you really want to learn the right way of doing things with Kamailio, the tool you should master is grep. Grepping code was much more useful than reading mailing lists or consulting the devel guide. Consider it an advice.


This post is a reminder to my brain who lately likes to forget basic things such an iptable rule to allow VPN clients to access internal LAN.

Yes, this afternoon I spent almost an hour and a half to try to figure out what went wrong with my newly installed openvpn. I was unable to access the LAN behind the server and I literally spent 90 minutes looking in the wrong place because my brain betrayed me and I completely forgot about adding a MASQUERADE rule to my firewall.

In my defense, I had problems with the installation, dependency problems and something close to the DLL hell that Windows has. This situation tricked me a lot because I assumed   this was the cause but when I decided to tcpdump the requests I saw the following:


# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
17:27:38.136712 IP > ICMP echo request, id 30234, seq 1, length 64
17:27:39.137333 IP > ICMP echo request, id 30234, seq 2, length 64


What! direct ping from tun to an IP visible only from eth0? Then I realized that I missed the:


# iptables -t nat -A POSTROUTING -j MASQUERADE




# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes

17:39:55.968160 IP > ICMP echo request, id 30234, seq 738, length 64

17:39:55.968757 IP > ICMP echo reply, id 30234, seq 738, length 64


I must have installed openvpn at least 4 times before today, but still wasn’t enough to remember the right thing at the right moment. Won’t happen again, hopefully :D.