 Do we need a microphone? Yeah. Thank you. You're welcome. It's working, but only for video recording. Perfect. Okay. Okay, let's start. Okay, another quick reminder that the speakers are not working, so the speaker has to speak louder and try to be as quiet as possible. So, now it's time for the next presentation. I have Henning, one of the main contributors of the Kamaila project, giving an update about what happened lately inside the project development and the ecosystem. Henning, thanks for coming and your floor. Thank you, Denon. Okay, yeah. So, just wanted to give you some updates, as Dennis said about what happened the last year basically in Kamaila. No? No, it works. Okay. Good. About the agenda, yeah. What is Kamaila? I will quickly go over it. You mostly know. What's new in the last release, 5.2? What changed in the development, in the Gitmaster branch, how we call it? Some updates on the contribution and community process. Yeah, a bit of an outlook about the release planning, the next major events that we are planning. Yeah, and of course some, maybe one, two minutes for questions. Okay, yeah. As Dennis said, I'm one of the major contributors in Kamaila. I'm with the project since 2007. I'm a core developer of the project, also a member of the management board and I work in all of the place, in core and databases. I did a lot of work, many, many modules. Yeah, I work as an IT manager, but I do also consulting for Kamaila and voice of IP services. What is Kamaila? Kamaila is a carrier-grade zip server. It's developed since 2001. It's especially useful for developing, yeah, large carrier-grade platforms for voice of IP. Services, real-time communication services, webRTC nowadays as well. It's also used a lot for scaling, yeah, application servers, PBX servers, like FreeSwitch, Asterix, and other services. Yeah, we have an active, really active development community. Last yesterday I pulled some statistics from GitHub. So in the last month alone, we had over 220 commits from 20 different authors. So this shows that we're really a broad project. We are open to contributions from everybody. We have a really good process now running as well with GitHub. We integrated 30 pull requests in the last month. And yeah, we did also denoted two maintenance versions in the last month. 5.2 is the, yeah, recent development branch, but the recent, sorry, stable branch and 5.1 is the last one before that. Yeah, Camelio uses a fairly traditional design, how to say, we have a small core. It does all the heavy lifting related to memory management, locking, transaction, stuff somehow. And then over 200 extension modules for everything you could imagine interfacing with external databases, this code in other places, APIs, et cetera, routing modules, support for zip RFCs, all kind of extensions. So what happened in 5.2? So some, yeah, a lot of things were changed in the core. We had a development hackathon, development workshop last autumn in Düsseldorf, sponsored from Zipgate. There we worked a lot on the module interfaces. We unified, we did the Ubeck unification of the model interfaces. Yeah, Camelio was developed since 2001, so there were different flavors of module interfaces that were unified. A lot of work from Denny, especially were done in the, yeah, Camelio scripting support. And now we also support a lot of modules for modern scripting languages like Python or Ruby or some other languages, JavaScript as well. So you don't need to learn the Camelio scripting language. You can use the scripting language where maybe you're already familiar in or have already some code in. And then of course a lot of internal parameters and APIs were extended, were added. You find the complete list here in our wiki. We also added a lot of new model modules. We can now do accounting in JSON. Also extended the application scripting support. We have now Ruby and Python 3 as well. Redis as a known SQL database was added as well as the database interface, new IMS modules and another, yeah, JSON module for the presence area. In total, more than 55 modules were also extended. Then we have extensions in the control commands, a new testing suite. Again, if you are interested in all the details, have a look to these URLs. Well, you find a complete list, several pages long for all the extensions that were done. Just some, some details. What happened in the module interfaces, in the module interface? So in case you, in your company, maybe you yourself have some proprietary modules which are not in the upstream for some reasons. This is the new module interface. Just, yeah, can look to the modules. This is the TM module, just as an example. So what we have, what we did was mainly, yeah, changing the order of some function calls and do some unifications there. Again, if you, if you want to have a look, also look to the modules. It's rather straightforward. You can also look to the commits in last, last autumn. How this was done for, for all these modules, just to give you like a small documentation in case you are, you need to work on that in preparation maybe for, for integrating modules that were done internally. Yeah, some stuff which is done at the moment. Like for my, for myself, also from Daniel. So I did a lot of work in the memory management area in the last month. So I did a complete review for, yeah, for all the memory management functions, function calls in the core. Yeah, fixed some errors around the way. So if you allocate memory, Camille will use an internal memory manager. Remember that every allocation can fail, every function call can fail. If you should look an error in this case, we introduced also some helpers which you can use to, to, yeah, output a generic logging message in this case. Would be great if you could use it, especially in new functions. You can also use this to output some additional information. Have a look to this commit if you need some, some example how to use it. There will be some more cleanups in the core related to memory management. Some years ago Daniel did some changes there. We have some, some redundancies in this area and I will continue to work there. Just do some cleanup. Yeah, that we have the less complicated core. I ideally can also better, that we can also better understand it, better maintain it. What we do on a regular basis, something that is also done for the last year, I would say also done right now, we use some external tools, the tools that scan, do some static code analysis in the core, also in the modules. And if we find some errors there, that library calls or like system calls are not implemented properly, we will of course fix this. More on a functional side, what happened in the development branch, interestingly is probably the addition of the RTP media server module. This is more or less the first time that really we, that we add some media handling to Camellio. So this module can be used to, to play some media directly from Camellio without the help of an external server like Asterix or FreeSwitch. It uses Gstreamer basically and then you can use this to play, play announcements. Still in development, there will be some switching functionality added soon from the also. So if you are interested in this, give it a try. Of course it needs some testing, I think it was added, just added some weeks ago. There is a new security related module, SecFilter, that can be used for blacklisting and other topics. Camellio supports now, with this was added, I think, some many days ago. Camellio did the merge. It was contributed from an author as well. And then we have, of course, usual extensions, just listed some in the record routing module, in the charge, charge accounting module, htable, variables, pipe, etc. Core DNS latency was added for logging that we have, can do this performance related logging There were several bug fixes in IMS. And this is again the link to the Wiki, if you are interested in the details. It's not that much there in the Wiki at least, because we are still in the beginning of the development phase. 5.2 was released last November, I think. Not more than two months development happened, maybe two and a half with the Christmas vacation. So, more to the community side. So, 2018 was the year of the Code of Contact in many projects. There was a big discussion, for example, in the Linux kernel community about this change. So, we also decided that we want to introduce the Code of Conduct. We did an extensive discussion in our management list about this topic. It's a political topic for some people, of course. So, we choose to base our Code on Conduct on the Debian Code of Conduct, which is a rather old Code of Conduct and a lot of development happens also for Debian. So, this was a good choice for us. I just did a quick summary about the headlines. It applies to communication in the project scope online or offline, but only in the project scope. We don't care what happens outside the project. This is a difference to some other Code of Conducts, but in my opinion an important difference. So, if you want to have a look to it, it's in the repository, of course. If there are any conflicts, if there are any discussions that are arising from the Code of Conduct, the committee to address the Camellia Management Board so far in the last months, nobody or nothing happened in this regard. Last year, nothing happened. We established it in the last October, as I mentioned, but before that, of course, the Camellia Management Board was available all the time. Nothing happened in the last years. We don't need to ban somebody from the company. This shows, as well, that we have a really good community structure that nevertheless, it's good that we have it. We are growing. We're having now more offline meetings, as well. Since seven years, we have the Big Camellia World Conference, for example. For a conference, it's also a good practice now to have a Code of Conduct. We want to add our part. Some changes in the last years or some extensions that were done was also to formalize the process more to how to contribute to our project. Daniel did a lot of work here. We using GitHub as many other projects. There is a contributing guide which is several pages long, which gives a lot of important helpful information that you don't need to run into the usual problems, how the commit message should be formatted, etc. In every case, if you have questions, you can contact our mailing lists. If it's a delicate maybe security-related question, there are also other channels, but we want to have it public, we want to have it open. If possible, ask on the development list. If you want to implement a major change, a non-trivial change, maybe a major module or some complicated chord changes, you should also ask first on the development list. Maybe there's some overlap with some other development. Maybe there's already a module which should be extended instead, so it doesn't hurt to ask before. We are pretty open with this regard to the commit access, so if you develop a new module, the module gets reviewed, and the module gets accepted, then you will get pretty, pretty soon also commit access to maintenance on this module. We are pretty open in this regard, maybe more open than other projects. And remember, of course, if you have a question, if you report a bug, if you open a pull request and you don't get a reply maybe in one, two weeks, send a friendly reminder, maybe somebody is in vacation or is traveling to a conference like FOSDEM, so people maybe take some days to respond, of course. In case you want to get your code in Camellio, how is our release structured, how we do releases, we use a time-based release schedule. A major version is released roughly every 10 to 12 months. We have a development phase of 8 months, and then a code freeze and testing phase of roughly 2 months. Depending a bit on the vacation, we usually avoid to have, of course, a release in the middle of the summer vacation, so this changes a bit over the years. And then, if the stable release is out, we do a minor release, roughly every one and a half to 2 months, depending, of course, on the bug situation. If there are some critical security issues maybe we will do it a bit earlier. The release is a bit older, maybe a bit longer term. The release date for the next major release, 5.3 probably, it's not fixed yet, we will do it probably in autumn, I would say, but it's not fixed. I think we will do an IRC conference, and probably also discussed on Camellio World about that and plan. As I said, we do mainly our development coordination over the email list, but sometimes also IRC conferences. In the case you want to get more involved into this community, the next major community event, where we also would probably do a developer meeting at Camellio World 2019, this will happen again in Berlin in the beginning of May. So in case you are interested, there is still the possibility to schedule or to propose a talk, I think. So in case you want to present about your project related to Camellio or related to WebRTC, to real-time communication, until middle of February, I think somehow the call for papers, call for proposals is open, so please consider this as well, it would be great. Okay. No. So that's all from my side. I think we have maybe three minutes for questions. Yeah, thank you. So easy view of the last years more from change of policies, but also from the new features, there are a lot of them as Henning gave a link there you can follow. So now if you have some questions about the project or I'm also available for answering if it's something more dedicated to my part of code. Any question? Perfect. Good afternoon. I will speak louder. As a company we use your products and we submit everything back of course, but how do you want more involvement of companies that use your product? Like how can we help you to maintain your project better? So the question is how you want the company using the product to get involved more? Are there any way that you would suggest that they follow? I mean it's good if you participate in the community of course. If you have some code that would be useful, you can of course contribute it and then maintain it of course would be great. You can also work on core parts or on maintenance tasks if you have resources or if your company want to sponsor this, this would be useful because like bug fixing extensions, this is not something that can be easily done with consulting work because customer normally pay only for new functionality and not for maintenance. So support with these maintenance, bug fixing, infrastructure work is always great. You can also if you don't have much time, maybe more money you can also sponsor of course the events, Camille World and for example you can sponsor the other ways also for sponsoring if you have some infrastructure we also