Wednesday, December 31, 2014

Happy New Year!

A very dynamic 2014 for Kamailio has reached its end! Many thanks to those contributing to it!
Looking forward to 2015, a lot of new features in Kamailio and new contributors! We wish a healthy and prosperous year 2015 to all Kamailio friends, hoping to meet many of you at Kamailio World Conference and other events around the globe!
Happy New Year!

Monday, December 29, 2014

Kamailio 4.2 Tips: #12 - Execute RPC Commands In Config

Although part of a new module in Kamailio v4.2 - jsonrpc-s - this bit worth a special mention: one can now execute RPC commands from kamailio.cfg using the function jsonrpc_exec(...).

The main purpose of these commands was the execution from external applications, but sometimes comes handy to get access to them.

Next example shows how to execute dispatcher.reload:

jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.reload", "id": 1}');

An useful use case for the above command can be execution in a rtimer route to perform period reload of dispatcher records.

Another example is to terminate an active dialog using h_entry and h_id.


The RPC command has to be given as parameter to jsonrpc_exec() in JSONRPC 2.0 request format.

There are over one hundred RPC commands exported now by Kamailio and the number is increasing with each major release -- no doubt that many of them can be useful to trigger from kamailio.cfg.

Enjoy it!

Friday, December 26, 2014

Kamailio 4.2 Tips: #11 - Dynamic Pipes and Limits

Pipelimit module in Kamailio 4.2 gives the possibility to add new pipes at runtime, specifying the algorithm and the limit. When using pl_check(...) with all three parameters, if the pipe is not found, it will be created:

# perform pipe match for authenticated user, creating the pipe if not found
$var(limit) = 20;
if (!pl_check("$au", "traildrop", "$var(limit)")) {

The limit can be adjusted later, by keeping the name and algorithm, changing the value for the third parameter. The parameters can be variables, therefore allowing full flexibility to name the pipe and set its limit.

Practically, with this version, pipes can be created as needed, not depending on record stored in database like with older versions. Here is one useful example: add pipes per each source IP, enabling new mechanisms to protect against unwanted traffic, like D/DoS attacks.

Enjoy it!

Wednesday, December 24, 2014

Merry Christmas!

Another year getting slowly to the end, an excellent opportunity to thank to all old and new friends of Kamailio project, from contributing code to using it, helping on mailing lists and other places online, or advertising it across the world!
Merry Christmas and Happy Winter Holidays!

Thursday, December 18, 2014

Kamailio World 2015 – Call For Speakers

Kamailio World is the conference for realtime communication with Kamailio and related projectsKamailio World Conference – now for the third year in Berlin in 2015!  Submission of presentation proposals for Kamailio World 2015 is open. Deadline for submission is February 15, 2015, notification of accepted proposals will be done latest on February 28, 2015.
Be aware that interesting proposals can be accepted before the deadline, we plan to have two intermediate review sessions before February 15, 2015, announcing any accepted presentations immediately. Therefore it is recommended to send your proposal as soon as possible, do not wait till deadline.
To submit the proposal, fill in the web form at:
The main topic of the conference is Real Time Communications, with the majority of the content being about Kamailio and other open source projects in the area. However, like for the past editions, we welcome very interesting presentations beyond those subjects.
If you are interested to look at the agenda from previous edition, visit:
Happy Winter Holidays! Looking forward to meeting many of you at Kamailio World 2015!

Tuesday, December 16, 2014

Maintenance Work on, Wed, Dec 17, 2014

A short note to say that server availability may be interrupted shortly after 18:00 (Berlin time), on Wednesday, December 17, 2014, due to scheduled maintenance work.
Among affected services:
  • main web site
  • wiki site
  • mailing lists: sr-users, sr-dev and business
  • downloads of tarballs
  • the GIT repository mirror on
Hopefully the downtime will be short and barely noticeable for most of the people!

Monday, December 15, 2014

Main Kamailio GIT Repository Hosted on Github

Today we moved the source code management away from an old server to a new infrastructure, based on Github. The main GIT repository that all developers use for development of Kamailio is now on a new address. The web link to it is:
The old server that was hosted by us became very old and is going to be decommissioned very soon.
For users (that cloned read-only from in the past) – it should be no change – just be sure that the DNS change has been propagated to you, because is pointing now to another server which has a real-time clone of Github repository. To know if DNS was updated on your side, browse to:
an you must be directed to Gitlist web interface:
If you end up in an URL with gitweb on it, the DNS cache on your side is still pointing to the old server.
The listed kamailio and sip-router projects are the same (the second is kept for historical reasons and it is a symlink to the first).
Gitweb is also running on the mirror, so the links from the email notifications of old commits are valid:
Once the DNS is updated, pulling/fetching in an existing clone done from should just work.
For developers – it requires to change the remote URL of your local clone to point to Github repository. Github provides access methods  via git/ssh or https: as an example of switching the remote URL to Github repository and do the push via https, got you your local clone directory and do:
git remote set-url origin
Check the change with:
git remote -v
You should see:
origin (push)
origin (fetch)
When you try to push, it should ask you for your Github username and password. For Github repository access, see more details at:
GITHUB OctocatFrom now on all new commits will be pushed to github!
Hopefully the migration is going to be smooth for everyone!

Wednesday, December 10, 2014

New Kamailio Module: statsd

A new module has been pushed to GIT repository: statsd. It was contributed by Eloy Coto, a recently added member to Kamailio development team.
The module provides the ability to send commands to statsd with different kind of information from the Kamailio configuration file. It provides native integration with statsd ( and graphite (

You can read more about the module at:
Eloy has also published an article about his development version here:

Tuesday, December 9, 2014

Kamailio - Shifting Main GIT Repository to Github

The Kamailio project has decided to move our source code repository, where all the developers contribute source code, to Github on Monday, December 15, 2015. The very old server that runs our current GIT repository for Kamailio is in desperate need of retirement.
There is already a real time mirror on Github and that is the one to become the main GIT repository – it can be found at:
The current domain will be kept and directed to a read only real time mirror of the GIT repository, therefore those users that installed Kamailio from GIT should not be affected.
GITHUB OctocatIf you are a developer with GIT write access and you cloned via ssh, you will have to change the remote URL to point to Github repository. You will be given write access to Github as well – if you haven’t sent your Github user id yet, email to

More updates will be posted once the switch is done.

Friday, November 28, 2014

New Kamailio Developer: Eloy Coto Pereiro

Kamailio project is glad to announce that a new person got developer GIT write access to repository: Eloy Coto Pereiro.
He has developed a new module named statsd, which offers a connector from kamailio.cfg to manage values in statsd collector application, enabling further monitoring via various tools such as graphite. The module will be merged to main repository in the near future, now is available at:
His git commit id is: eloycoto
A warm welcome and looking forward to future work within the project!

Monday, November 24, 2014

Deploying Kamailio with Puppet

Giacomo Vacca from Truphone, one of the very active community members promoting our project, has published a blog post on how to deploy Kamailio using Puppet.
Puppet describes itself as configuration management system that allows you to define the state of your IT infrastructure, then automatically enforces the correct state. Whether you’re managing just a few servers or thousands of physical and virtual machines, Puppet automates tasks that sysadmins often do manually, freeing up time and mental space so sysadmins can work on the projects that deliver greater business value.
Such knowledge is extremely useful and can save precious time to everyone handling installations of Kamailio and can be extended to manage the deployment of other components.
As a project, Kamailio welcomes everyone that shares its experience and expertise, being more than happy to publish news about similar article and even host them if that makes it more convenient for the author. Do not hesitate to contact Kamailio team!

Tuesday, November 11, 2014

Kamailio v4.2.1 Released

Kamailio SIP Server v4.2.1 stable is out – a minor release including fixes in code and documentation since v4.2.0 – configuration file and database compatibility is preserved.
Kamailio (former OpenSER) v4.2.1 is based on the latest version of GIT branch 4.2, therefore those running previous 4.2.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.2.x.
Resources for Kamailio version 4.2.1
Source tarballs are available at:
Detailed changelog:
Download via GIT:
 # git clone git:// kamailio
 # cd kamailio
 # git checkout -b 4.2 origin/4.2
Binaries and packages will be uploaded at:
Modules’ documentation:
What is new in 4.2.x release series is summarized in the announcement of v4.2.0:

Friday, November 7, 2014

Kamailio v4.0.7 Released

Kamailio SIP Server v4.0.7 stable is out – a minor release including fixes in code and documentation since v4.0.0 – configuration file and database compatibility is preserved.
Kamailio (former OpenSER) v4.0.7 is based on the latest version of GIT branch 4.0, therefore those running previous 4.0.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.0.x.
Note that branch 4.0 is now the 3rd old stable branch. The latest stable branch is 4.2, at this time having release of v4.2.0 out of it. For the future, the project is focusing on maintaining the last two stable branches, at this moment being 4.2 and 4.1.
Resources for Kamailio version 4.0.7
Source tarballs are available at:
Detailed changelog:
Download via GIT:
 # git clone git:// kamailio
 # cd kamailio
 # git checkout -b 4.0 origin/4.0
Binaries and packages will be uploaded at:
Modules’ documentation:
What is new in 4.0.x release series is summarized in the announcement of v4.0.0:
Note that 4.0.x is the 2nd previous stable release series, being followed by 4.1.x and the latest stable one is 4.2.x, you can read more about it at:

Thursday, November 6, 2014

Kamailio v4.1.7 Released

The Kamailio SIP Server v4.1.7  stable version  is released. This is a minor release including fixes in code and documentation since v4.1.6 – configuration file and database compatibility is preserved. We recommend all users of 4.1.x versions to upgrade to this new version – no configuration changes are needed.
Kamailio (former OpenSER) v4.1.7 is based on the latest version of GIT branch 4.1, therefore those running previous 4.1.x versions are strongly advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.1.x.
Note that branch 4.1 is the previous stable branch. The latest stable branch is 4.2, at this time having release of v4.2.0 out of it. The project is officially maintaining the last two stable branches, at this moment being 4.2 and 4.1.
Resources for Kamailio version 4.1.7
Source tarballs are available at:
Detailed changelog:
Download via GIT:
 # git clone git:// kamailio
 # cd kamailio
 # git checkout -b 4.1 origin/4.1
Binaries and packages will be uploaded at:
Modules’ documentation:
What is new in 4.1.x release series is summarized in the announcement of v4.1.0:
If you want to see what is new in the latest stable version in 4.2.x series, see release notes for v4.2.0:

Friday, October 31, 2014

Kamailio 4.2 Tips: #10 - Lightweight retransmission detection

UDP is still most common transport used for VoIP (hopefully that will change soon -- for proper security and privacy, TLS must be used), but by its nature of unreliable transport layer, applications must retransmit SIP packets over UDP if the next hop is not sending a response in very short time (typically, the first retransmission is done after 500ms, if no response was received). On mobile networks or congested paths, retransmissions happen quite often. The ability to detect quickly and handle them efficiently can improve the performances on SIP server side.

With the old versions, the retransmission of a request was handled by tm module, creating the transaction, then same requests were matching the transaction and processed appropriately. As early the transaction was created during the config file execution, as quick the retransmission was detected.

But a transaction is quite big structure (has space to store incoming request, its outgoing branches as well as relevant responses), creates timer tasks and uses shared memory, the last two require synchronised access, thus having impact on performances. Also, in many cases, requests are replied locally (e.g., destination user is not online, the request has to be authenticated), but the decision to reply can take a bit (e.g., a database query has to be performed for authentication).

Creating the transaction and destroying it quickly, because the request was not forwarded, doesn't sound the most optimal approach. Processing a retransmitted request till it is about to relay it stateful and see at that moment it is a retransmission, it is also affecting performances (e.g., extra database queries are done).

Kamailio 4.2 introduces a lightweight layer, which can be used between receiving a request and creating the transaction, for detecting and handling retransmissions. TMX module can keep track of requests processed at a moment by all SIP worker processes. Instead of a full transaction structure in memory for each request, it uses a very small structure per worker process in memory, keeping only the attributes needed to match the retransmission -- again, it is not a structure per SIP request, but per SIP worker process, given that at the end of configuration file execution, the worker will create the transaction if the request is relayed.

To benefit of this feature, you have to use t_precheck_trans() function. Default kamailio.cfg for v4.2 includes it -- the handling of retransmission is done by:

    # handle retransmissions
    if(t_precheck_trans()) {

The logic behind the above config snippet:

  • if the request is handled by another process (t_precheck_trans() returns true), then use t_check_trans() to send the appropriate reply in the eventuality the transaction was created by that process and exit
  • if the request is not handled by the another process (t_precheck_trans() returns false), then use t_check_trans() because the transaction might have been created before

Within a configuration file that creates other large structures for calls, such as dialog, this feature becomes even more useful.

Enjoy it!

Wednesday, October 22, 2014

Kamailio 4.2 Tips: #9 - Asynchronous Route Execution - DNS

I got dragged back in the asynchronous loop by several folks here at AstriCon, so again another tip for it.

Kamailio had a lot of asynchronous processing options for many years (including the transport layer TCP /TLS). Kamailio 4.2 brought in more options or simplified some of the existing alternatives. See also some of the previous posts in this series.

The subject of this post is asynchronous config route block execution. Technically it is about delegating immediate execution of a group of actions from configuration file to another process than the SIP worker and can be used for various needs, not tied to something specific. For that reason, the example is about doing sort of asynchronous DNS handling (dedicated to Torrey, developer of sipt module, following the discussion after AstriDevCon day, at this moment busy with the hackatron).

There is a lot of SIP traffic that doesn't require DNS -- for example: traffic terminated on the server, like REGISTER, presence requests, requests within dialog, calls between users registered locally (location service). Likely to have an hostname as next hop address are: requests sent to foreign SIP providers or calls sent to PSTN termination providers. Depending on the type of the service, there can be more or less percentage of SIP requests that need to do DNS lookup. However, DNS query can take a while, so it is an obvious benefit of avoiding such operation in a SIP worker.

How to do it: first, the number for asynchronous workers has to be set via global parameter: async_workers. Then, the async module provides a new config function: async_task_route("rname").

The missing piece would be how to decide whether forwarding of the message involves DNS or not. That is simple to do with:
  • $nh(d) - variable returning the next hop domain
  • is_ip(...) - function exported by ipops module which can detect if an address is IP or not
Next are the relevant config snippets:

request_route {
    if(!is_ip("$nh(d)")) {
        if(!async_task_route("DNSRELAY")) {
            send_reply("500", "Server error");

route[DNSRELAY] {
    if (!t_relay()) {
        t_reply("500", "Server error");

Enjoy it!

Tuesday, October 21, 2014

Kamailio 4.2 Tips: #8 - Asynchronous Accounting to Database

One of frequent database operations done by Kamailio is inserting accounting records. Some of database servers or additional software (sql proxy) offer solutions to speed up such operations, but typically they come with limitations. Such mechanism would INSERT DELAYED offered by MySQL, but it doesn't work for InnoDB tables.

Kamailio 4.2 introduces the option to do the accounting to database using the asynchronous framework from core, provided that database connector module has support for it. This feature can be enabled by setting the acc module parameter db_insert_mode to 2.

modparam("acc", "db_insert_mode", 1)

At this moment, db_mysql module is able to do asynchronous queries, so it has to be used for accounting. Expect other database drivers to implement this feature in the near future. If db_insert_mode is 2 and database connector module doesn't support asynchronous query, then normal insert is performed.

Enjoy it!

Monday, October 20, 2014

Kamailio 4.2 Tips: #7 - Increment CSeq for Proxy Authentication Done by Server

Using uac module, Kamailio was able to do authentication to the next hop for quite some time. For example, this could be needed when sending traffic to a PSTN termination provider which require to authenticate by username and password.

But there was a limitation: CSeq was not incremented for the INVITE sent with credentials - which was making authentication not-fully RFC compliant. The authentication worked if the other party was using Kamailio (or SER/OpenSER).

The dialog module in Kamailio 4.2 has now the capability of detecting that the authentication was done by Kamailio (via uac_auth() from uac module) and increment the CSeq for the INVITE with credentials header. Subsequent messages in the same dialog will get the CSeq value adjusted accordingly.

This feature has to be enable by setting dialog module parameter 'track_cseq_updates':

modparam("dialog", "track_cseq_updates", 1)

Note that the call (starting with initial INVITE) has to be tracked with dialog module (i.e., use dlg_manage() for requests belonging to that call).

Enjoy it!

Sunday, October 19, 2014

Kamailio 4.2 Tips: #6 - Multi-part body management

It was not very common to have SIP messages with multi-part body, but in context of SIP-I/T or instant messaging and presence, or even emergency services, such bodies can occur.

Kamailio 4.2 is a big step forward to simplify the management of multi-part body from configuration file. Textops module introduced three dedicated functions:
  • set_body_multipart( [txt, content_type] [, boundary])
  • append_body_part(txt, content_type [,  content_disposition])
  • remove_body_part(content_type)
All together, they give the option to convert to a multi-part body, set or add a part and remove a part from the body.

Here are some examples:

append_body_part("7e Od 04 55 75 69 20 4d 61 6b 65 43 61 6c 6c",

Resulting content in the body is:

Content-Type: application/vnd.cirpack.isdn-ext
Content-Disposition: signal;handling=required

7e Od 04 55 75 69 20 4d 61 6b 65 43 61 6c 6c


Removing some part, can be done with:


Enjoy it!

Saturday, October 18, 2014

Kamailio 4.2 Tips: #5 - Read configuration file from standard input

Kamailio is reading configuration file by default from Linux standard paths:

  • /etc/kamailio/kamailio.cfg - when installed via packages (e.g., deb, rpm)
  • /usr/local/etc/kamailio/kamailio.cfg - when installed from souces
A custom path to a configuration file can be given using -f command line parameter:

kamailio -f /path/to/kamailio.cfg

Actually it doesn't even matter the file name, can be anything, not only kamailio.cfg. As a side note, with this option, you can run multiple instances of Kamailio on same box, from same installation file, just be sure you have configs with different listen socket (e.g., different IP address or port or protocol).

Kamailio 4.2 adds the option to read the configuration file from standard input: the value for -f parameter has to be - (dash line). It is very unlikely than one would like to type the configuration file via keyboard, but can be useful to pipe the output of another application to Kamailio. That application has to print to terminal (standard output) a Kamailio configuration file) to Kamailio.

This can be useful for:
  • keep configuration files on a centralided system and get it only when starting Kamailio -- could increase the security by not storing locally a file that has credentials to connect to database
  • write an application that embeds kamailio.cfg and prints it based on a key -- the key can be used also for encrypting the embedded kamailio.cfg, increasing the security
For example, next is the command to get latest kamailio.cfg from Kamailio repository with wget and start Kamailio without storing the configuration file locally:

wget -qO- --no-check-certificate \ \
   | kamailio -f -

Note: the command expects Kamailio to be installed from source code (i.e., with modules in /usr/local/lib/kamailio/modules).

Enjoy it!

Friday, October 17, 2014

Kamailio 4.2 Tips: #4 - Asynchronous SQL Query

SQLOPS is the module giving the tools to perform SQL queries to different databases from configuration file and have the result in variables. But in many cases the result doesn't matter, think about pushing statistics to database in order to have a web application rendering some graphs or displaying various reports.

With older versions, you could use a combination of mqueue, rtimer and sqlops to do kind of asynchronous database operations.

Now, Kamailio 4.2 has a new function - sql_query_async(...) - that delegates the database operation to be done in one of the processes from async pool (new in 4.2 as well). The SIP worker process is immediately ready to process next task in the config or handle next packet from the network. The config file is simpler and performances are higher.

sql_query_async("ca","INSERT INTO regstats(username, time) VALUES('$au','$Ts'");

Enjoy it!

Thursday, October 16, 2014

Kamailio v4.2.0 Released

October 16, 2014: Kamailio v4.2.0 is out –  a new major release, collecting new features and improvements added during about eight months of development and one and a half month of testing.
In short, this major release brings 10 new modules and enhancements to more than 60 existing modules, plus components of the core and internal libraries. Detailed release notes are available at:
Development for next major release, 4.3.0 (expected to be out around mid of 2015) has started already. Watch the project’s webside closely for further updates and news about evolution of Kamailio.
Enjoy SIP routing in a secure, flexible and easier way with Kamailio v4.2.0!
Thank you for flying Kamailio!

Wednesday, October 15, 2014

Kamailio 4.2 Tips: #3 - Send arbitrary data packet from config

Ever needed to send a custom 'notification' when some event happened while routing SIP packets?

UAC module provided for many releases the mechanism of sending new SIP requests at any point in configuration file, but sometimes SIP headers can be unnecessary overhead (but of course, that is balanced by all the other benefits of SIP, like flexible routing, re-using Kamailio as receiver, a.s.o.).

Anyhow, for simplified needs and not only, with version 4.2.0, corex module introduces send_data(uri, content) config function. The URI is still a SIP address, allowing in this way to choose any of supported transport layers (UDP, TCP, TLS or SCTP). The content, while is limited to text format if specified in config file, can be structured the way it fits the best (e.g., xml, json, line-oriented).

Here are some examples:


send_data("", "$fU,$rU,");

      "Caller: $fU\nCallee: $rU\nTime: $ts\n\n");

Enjoy it!

Kamailio 4.2 Tips: #2 - Hash table iterator

Htable module is among most popular ones when coming to building flexible and customised routing policies in kamailio.cfg. So far the access to the content of an hash table was possible by knowing the key of the item.

Starting with Kamailio 4.2.0, you have the possibility to walk through htable content via an iterator, accessing the key and value for all items. Three new functions (to initialise the iterator, go to next item and end iteration) along with two new script variables (to retrieve the key and the value for current item) give the tools for using this functionality. Next snippet presents how to print the items (key, value) for htable h1:

sht_iterator_start("i1", "h1");
while(sht_iterator_next("i1")) {
    xlog("h1[$shtitkey(i1)] is: $shtitval(i1)\n");

More details about this feature can be found in the readme of htable module:

Enjoy it!

Tuesday, October 14, 2014

Kamailio 4.2 Tips: #1 - Log message prefix

Quite long time since I haven't posted here on technical subjects related to Kamailio. Being just around the corner of a new major version release, 4.2.0, I am going to have a small series of short posts to reveal some of the new tiny bits that can improve a lot your experience managing Kamailio.

Tip #1 - global parameter: log_prefix

It can be used to specify the text to be prefixed to each log message printed by Kamailio while processing the SIP message.

An immediate benefit could be for log messages added in kamailio.cfg via xlog module functions. If you want to match the log message with packets from a network trace, you have to print several details from SIP packet. For example, such list of details can be:
  • sip message type
  • source ip
  • sequence number
  • sip method type
  • call-id
In addition, the xlog message would have some extra text to describing its role.

With older versions, that was possible by listing those elements in each xlog, like:

xlog("$mt $si $cs $rm $ci - extra text one\n");
xlog("$mt $si $cs $rm $ci - extra text two\n");

With 4.2, it can be done like:

log_prefix="$mt $si $cs $rm $ci - "
xlog("extra text one\n");
xlog("extra text two\n");

An useful effect is that log messages printed from inside the C code will be prefixed as well. Many of the error messages in C code don't print any details of the SIP message processed at that moment, now you can overcome it without touching the C code.

As a bonus, remember that you can have different log level for core and each of loaded modules by using debugger module and setting the appropriate mod_level parameter, even in v4.1.x.

Enjoy it!

Wednesday, October 8, 2014

Kamailio Git Branch 4.2 Created

The 4.2 branch on Kamailio GIT repository  has been created. This is the official branch to be used for releasing any of the 4.2.x versions. The first one, v4.2.0, is expected to be released in one week.
The version used now in master branch is prefixed with 4.3.0, which is expected to be the next future major release. From this moment,  developers are free again to commit new features and changes to the master branch, code that will be part of the 4.3.0 major release.
Branch 4.2 is an official stable branch and will only be the target for bug fixing and documentation improvements commits. If you want to install Kamailio from branch 4.2, follow the guidelines at:
Report any issue to .
Your feedback is very appreciated and you will help getting Kamailio v4.2.0 as stable as possible at the time of release.

Tuesday, September 30, 2014

Astricon 2014

Kamailio is going to have a rich presence at Astricon 2014, Oct 22-14, 2014, in Las Vegas, USA – the event focusing on Asterisk and the eco-system around it.
With a close collaboration between the two open source projects, starting from early 2000 years, expect high quality talks approaching how-to and use case tutorials about combining Asterisk and Kamailio to build, secure, scalable and innovative real time communication systems and services.
Daniel-Constantin Mierla, Peter Dunkley and Giaccomo Vacca from Kamailio community will give presentations and are ready to meet on site and discuss with everyone interested in learning more about Kamailio and how to integrate it with Asterisk.
Looking forward to meeting you in Vegas!

Monday, September 29, 2014

SIPit 31 – Nice, France

The 31st edition of SIPit – SIP Interoperability Testing event – starts in Nice, France, organized by SIP Forumand hosted by ETSI. Kamailio is participating in the tests as well as running as part of the SIPit infrastructure network in the automated self-tests.
Spanning across all the week, Sep 29 – Oct 03, 2014, the event is the place where SIP implementers of various products, from phones, libraries to gateways, servers or testing tools, meet for testing products with each other or in multi-parties test scenarios.
Along the years, our project was a frequent participant, no matter the name was at that time SER, OpenSER or Kamailio. This edition, Daniel-Constantin Mierla from Asipto and Olle E. Johansson from Edvina are there, making sure that the upcoming major version 4.2.0 is rock solid, ready to roll out in production once released. They might be less active on mailing lists, but for the benefits of all, heavily testing and stressing Kamailio.
Watch the twitter feeds for @miconda@oej and @kamailioproject for fresh notes from the fields!

Friday, September 26, 2014

KazooCon 2014

Kazoo, the open-source, scalable, distributed, API-driven, cloud-based telephony platform using Kamailio as SIP routing engine, is having its annual conference in San Francisco, USA, during Oct 6-7, 2014 – KazooCon.
It is one of the conferences that must be attended if you are looking to start your own telephony services in short time, based on top and modern technologies.
Upcoming major version of Kamailio, 4.2.0, expected around mid of October, includes the Kazoo connector module, making deployments of Kazoo easier to synchronize with upstream Kamailio packages.