Any Valid Up-to-date Info About Kamailio-Asterisk Integration ?

Home » Asterisk Users » Any Valid Up-to-date Info About Kamailio-Asterisk Integration ?
Asterisk Users 2 Comments

Hi all

Have recently watched Matt Jordan‘s session on Kamailio World 2014

On slides 26-29 of his presentation
(http://www.kamailio.org/events/2014-KamailioWorld/day1/09-Matt.Jordan-Asterisk12-And-PJSIP.pdf)
he speaks about a (completely new, for me at least) approach to build scalable telephony systems, using N instances of Kamailio and N
instances of Asterisk

Are there any whitepapers, howtos, “implementation experience reports”, whatever, available, that would describe such an approach in details and help some not-so-advanced admins to at least understand “if is it what they need, or not exactly, or not at all” ?

We are planning to look closer at Kamailio (or any other proxy, like OpenSip) as a way to do both load-balancing and failover solutions, so that refusal of any Asterisk instance should have minimal possible effect on the overall system availability.

A lot of questions howevere arise, like: what if one SIP user got REGISTERed at Server 1, and the other on Server 3, so how can they call one another ?

Also, outbound registrations can be done from one instance at a time, say it’s done from Server1 for Trunk1, so how can users, that got authenticated at Server2, call thru that registration (Trunk1) ?

Also, Kamailio itself has to be protected from failing, and probably even from overload…

Would be great to read something in-depth about that

Thanks!!

Kirill Marchuk

2 thoughts on - Any Valid Up-to-date Info About Kamailio-Asterisk Integration ?

  • The best documentation out there – that I’m personally aware of – is Daniel’s guide on integrating Kamailio and Asterisk:

    http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb

    While there have been quite a few improvements made in Asterisk (and I
    imagine, Kamailio as well) since that was written, that guide would be a good starting point, regardless of the versions involved.

    There are many different ways of handling this.

    First, you have to ask yourself what you want Asterisk and Kamailio to do in your set up. Some sample questions:
    * Who acts as the registrar?
    * Who manages subscriptions?
    * Should each Asterisk server have a special purpose, or should they be treated as a generic pool of media servers?
    * Should Asterisk be involved in ‘normal’ calls (two-party, no media manipulation), or should it only be used when special services are needed?

    Your goal, in any scenario, should be to keep the Asterisk dialplan as simple as possible. That typically means not placing customer specific logic in the dialplan, but instead relying on func_odbc to pull customer specific information from a database. In later versions (such as Asterisk 13), you can remove much of the logic from the dialplan and use ARI to build custom media applications.

    But no, not a lot of this is written down yet.

    If your Asterisk servers are sitting behind Kamailio, they should probably just be registering to their Kamailio instances. Again, if Kamailio is handling the registration, identification, and authentication, then you probably don’t want Asterisk doing any of that. You would instead just have Asterisk “trust” that Kamailio is sending it the right calls, and have it handle them accordingly.

    That’s pretty standard stuff for Kamailio.

  • From Kamailio point of view, the tutorial referred here
    (http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb)
    should be quite actual. As Matt said, we do have new features with more recent releases 4.1.x and 4.2.x but the relevant parts in the relation with Asterisk (authentication, registration, etc.) are more or less the same.

    If Asterisk preserved pretty much its old realtime mechanism and database structure, then should be straightforward to adjust in case of small changes.

    I hope to get a new tutorial that uses latest Kamailio and Asterisk 13
    in the near future, targeting to use ARI instead of database for making the integration of the two applications.

    Cheers, Daniel