So now we’ve made a functional bare-bones PBX using Kamailio, and we’ve touched upon a few of the key functions Kamailio can do, but let’s go over them again to recap.

Future Kamailio posts I’ll be talking about using specific modules and using Kamailio for specific use cases, such as load balancing traffic between carriers and monitoring their up/down status, scaling Asterisk by front ending it with Kamailio, adding/rewriting/removing headers with Kamailio and stateful vs stateless operation, so stick around, but here’s an overview of what we’ve learned.

Routing Blocks & Structure

Routing blocks make code cleaner and allow reuse of the same blocks, you can call a route to do a function without having to write out what to do every time.

In the below example we go from the default “request_route” block, where all new messages start, and jump to the block named “RESPOND_501”.

request_route {
        route(RESPOND_501);    #Jump to the RESPOND_501 block
}

route[RESPOND_501]{
        sl_reply("501", "Not Implemented");   #Send 501 reply
}

From RESPOND_501 we send a stateless reply to whoever sent us the message.

We introduced xlog to write data to the log, and then viewed that data in Syslog.

xlog("Hello, I am in the request_route");

We determined the SIP method of the request using

if(method=="INVITE"){

to tailor our responses based on the method used.

Kamailio as a SIP REGISTRAR

This was covered in Part 4 of Kamailio 101,

The main takeaway from this was the use of

save("location");

We expanded this to only for REGISTER messages and to stop processing after the location was saved.

        if(method=="REGISTER"){
                save("location");
                exit;
        }

Then we used kamcmd for the first time to dump the user location so we could see our registered endpoints.

 
kamcmd ul.dump 

First Call

Building upon having saved the location of registered endpoints we looked up the locations we had Address on Record entries for and forwarded the traffic to them, to allow to make calls between registered UAs.

       if(method=="INVITE"){
                lookup("location");
                t_relay();
                exit();
        }

Quickly we saw issues with this though, if the UA we wanted to reach wasn’t registered, if we hung up before the called party answered, and a host of other scenarios,

We addressed the user not registered scenario and then talked briefly about the routing blocks that come with Kamailio and how they’ll be our savoir.

Reusing Code

We put back the default routing blocks that come with Kamailio after highlighting the difficulties with trying to do everything yourself.

We talked about how route(RELAY); will better handle message relaying than tm_relay(); alone, and using route(WITHINDLG); to manage within dialog requests & branching.

Security in Theory

We talked about the importance of AAA (Authentication, Authorisation & Accounting) and the perils of naming your son Bobby Droptables.

Security in Practice

We put what we talked about into practice.

Using a database back-end (MySQL) we setup our UAs to be authenticated when registering and before making calls, and listed our Carrier’s IPs so we’d only accept inbound calls from our carrier, not random folks online.

We used kamctl to add users and manage address groups.

route(REQINIT); was used to manage traffic validation.

auth_challenge(“$fd”, “0”); was used to authenticate UAs

and (allow_source_address(“200”)) was used to authenticate carriers.

Adding Carrier Links

Lastly we put all the pieces together and put in a carrier link / trunk to allow calls to be made / from to the PSTN using rewritehost()

So where to now?

You’ve made it to the end of this tutorial, but chances are it’s only the beginning of your Kamailio journey.

There’s a lot of posts on this site regarding Kamailio and it’s many modules, uses and functionalities, explore and good luck!