Re: [SR-Users] Kamailio and Asterisk integration

Roman, On 11/12/2011 11:18 PM, roman dmytriv wrote: The reason I am giving you nebulous, seemingly intractable responses to your questions, in this thread and the other, is because I am encouraging you to habituate your mind to a slightly different mode of thinking that is more appropriate to the sort of thing that Kamailio is. In this case, you should really decide what it is that you want to provide and then reason backward to the appropriate tools for it. It is true that to do that, you must first know what it is that can be provided, in principle, but the way to do that is to learn how VoIP networks and application services are built in general, conceptually. Kamailio does have some highly specific features appropriate to certain situations, but fundamentally, it is a particular kind of building block, but a very amorphous one. What I can tell you with great certainty is that combining elements like Asterisk as an end in itself--that is, purely for the sake of doing so--is a pointless waste of time, and you should first decide what you want to provide and then determine if it is appropriate to do that, not decide to combine them and think about what can be done with that. Integration is a task full of specific details tailored to the intended result; you can't (usefully) generically integrate, in an undifferentiated, unspecialised sort of way. Kamailio is a SIP proxy at its core, though it has some SIP server features of which it is the logical endpoint, such as the registrar and presence server. It has also acquired some light UAC functionality of late, such as handling registrations and digest authentication, etc. In addition, it is well-suited for translation between various SIP transports, and as a gateway to some other protocols such as XMPP. You may have noticed by now that Kamailio is driven by a programmatic route script, and that rather SIP message handling is presented within this script in a rather low-level way that requires an understanding of the fundamentals of SIP protocol mechanics, as well as its various state machines. This aspect of Kamailio makes it rather like an SDK or a framework in many ways. Yes, it's driven by a proxy and UAS core, but the user really scripts their desired SIP outcomes in a detailed way for virtually every type of message, though some are more automatically handled than others. In this sense, Kamailio is not like Asterisk at all; Asterisk is an application with a great deal of pre-determined, built-in functionality, and you can turn it on with just a few configuration file changes. Kamailio's not really like that, although the packaged, stock config file has been getting more and more user-friendly I suppose. Even then, Asterisk has a myriad of integration paths and scriptable possibilities (dial plan, AGI, AMI, etc.) that leave the question of what can be done with it somewhat open, but it is definitely an easier question to answer than for Kamailio. So, the question of what can be done with Kamailio, or even the ways in which a Kamailio server can accessorise or enhance an Asterisk element, really is a very open-ended one. It is a challenge of imagination; there are literally at least thousands of logically possible ways to combine these two things, just as there are lots of ways that Asterisk+a2billing and Kamailio can interact. What you need to ask yourself is: why do I want to combine them? Where did you get this idea? Did someone tell you? Did you find a page about integration on the web? If so, what were you searching for? Why? What is the problem you are trying to solve? What do you want to accomplish? Perhaps the answers to these questions can flesh out some sort of broad underlying purpose, some thematic continuity. Certainly, there are some "typical" ways in which Asterisk and Kamailio are often combined: - Load balancer: with judicious use of a database or IPC mechanism, applications delivered on Asterisk can be horizontally scaled across N nodes by putting a round-robin load balancer in front of them--a task for which Kamailio's "dispatcher" module is very well-suited. - Centralised registrar: large numbers of endpoints can be concentrated in one server and serviced by multiple Asterisk servers. - Carrier interface: business layer of outbound dialing from Asterisk servers (e.g. LCR) can be handled by Kamailio. - Core platform router: a Kamailio proxy can route calls to application-specific Asterisk feature servers like voicemail, conferencing, etc. And many others. But really, none of those represent essential or rigourous answers to your question. They just impose certain premeditated scenarios that may or may not be appropriate to what you want to accomplish, and simply answering with a few examples under the heading of "here's what you can do" would do you a disservice by limiting the paradigms in which you are thinking. Kamailio does have some very specific features useful to meet very concrete requirements, once you've decided what you want to do broadly. You can get an overview here: http://www.kamailio.org/w/features/ And you can take a look at the various available modules here: http://www.kamailio.org/docs/modules/3.2.x/ Some of these modules are de facto "core", in the sense that while they are not formally part of the server core, they are likely to be essential dependencies of any practical or commonplace use of Kamailio. These include 'tm', 'sl', 'rr', 'pv', 'xlog, etc. Some of these modules primarily exist to export APIs or generic mechanisms to other modules that use them in specific ways that expose functionality to the end-user, such as 'usrloc' and 'pua'. And some others of these modules provide very concrete features. For instance: - dispatcher: Various kinds of load balancing/distribution. - pipelimit: Rate limiting. - drouting & lcr: Some dynamic routing structures. - nathelper & rtpproxy: Far-end NAT traversal fixups and dynamic control of external third-party RTP relays. - memcached & ndb_redis: Support for Memcached and Redis key-value stores. - db_mysql/postgres/unixodbc/oracle & sqlops: Support for SQL interaction with various relational databases. - dialog: Make the proxy statefully aware of dialogs, not just transactions, which is useful in limiting number of concurrent calls, etc. - geoip: Integration with Max Mind GeoIP database for regional identification of IP addresses. - xhttp: Integrated HTTP server. ... and a whole lot more. You really need to decide what it is you want to do. These modules provide interesting possibilities, but they are, for the most part, implementation details subsumed under larger architectural and service delivery objectives. In other words, as a methodological matter it would be quite uncommon to say: "Oh, Kamailio has a GeoIP module, so now I've figured out what I want to provide!" You could have implemented "geo IP" in some other way if you wanted, even if the module didn't exist; Kamailio's route script is very flexible and quite evolved at this point, and offers many types of connectors, integration paths, API hooks, management interfaces, etc. You have to have some idea of what you want to do first. I suggest educating yourself about the basic principles of VoIP networks and how services are built. I would learn about: - The purpose of the SIP protocol, in the context of the history of telephony and signaling. - SIP protocol structure, syntax, etc. - Types of SIP network elements: UACs, UASs, proxies, registrars, B2BUAs, SBCs, and what they all do. - RTP, media and codecs. - PSTN interworking, billing, rating, etc. - Various types of application backends, i.e. open-source like Asterisk, FreeSWITCH, SEMS (SIP Express Media Server), etc., and some proprietary approaches like VoiceXML and ccXML -- you should be aware of them, at least. Then, I would come back to Kamailio with a greater understanding of the "big picture" of what it is and ask: what can it do for me generally and specifically? Generally in terms of being a proxy+UAS, and specifically in terms of the modules and higher-level features it offers. -- Alex