 All right, so my name is Matthew Fedrickson for those who are not familiar with me. I'm the project lead for the asterisk project I just want to start off first and ask how many of you are familiar with asterisk Okay, this is great. I wasn't sure it's been around for a long time But you know the world has changed quite a bit, and I just want to make sure that I understood the audience I was speaking with so Let's get started So For those of you who are familiar with the background of the asterisk project It was kind of the baby of Mark Spencer who started the company Digium about 15 years ago or 20 around 15 20 years ago and So it's been a critical part of Digium there's been a lot of developers within Digium as well as outside of Digium that have contributed to it, but Digium has kind of been a big part of of asterisk life for a very long time and Just this last year for those who aren't familiar Digium was acquired by a company called Sangoma, and you may notice that Sangoma That the new Sangoma logo for those who are familiar with the old logo has acquired a little bit of asterisk flair to it So so yeah, I mean, you know the world's not on fire or anything like that for those that are concerned Asterisk is still a very important part of Sangoma it was important part of Digium and now is also very important Sangoma as well They have a lot of products and projects internally that utilize asterisk and so it's it's still safe in terms of of its company stewardship I just wanted to talk a little bit today About some of the things that happens That's what I try to do is for those of you that are not able to attend the yearly asterisk conference in Astrocon I try to come here to this conference to be able to update everybody on what's happened in the world of asterisk Just by a raise of hands, how many of you utilize asterisk somewhere in your network or deploy it or something like that Oh, this is wonderful. All right. Great. How many of you develop applications based on asterisk? So maybe not like utilizing pre-built functionality in asterisk But maybe like utilizing APIs and things like that in asterisk to build higher-level applications. Yeah, more hands-worth. This is great Actually, this is really good. Okay, cool. So I'm going to talk about some things that are probably going to be interesting to many of you So Just kind of in review Astros 15.x received a number of bugfix releases this last year This is actually pulled from a lot of my slides from Astrocon, which was in September So some of the numbers may line up more with September's time frame But the current version of 15 is 15.7.1 Current version of 14 is 14.7.7 and actually it is dead It is end of life because it was it was a standard release and it went end of life Right around the time we released 16 back in September And Astros 13 is still it is an LTS and it is still current. There's still there are still New releases that are made of that branch and will for the next few years Over the course of the past year since Astrocon There were 3300 merged code reviews across all the branches that we support and for those of you that are not familiar with the Development level of Astros is we support multiple release branches at the same time. We allow We have a very good test infrastructure in Astros and allows us to be able to be a little bit more bold in terms of how We manage those branches and and we even allow new features and functionality That are non-breaking to enter those branches You know assuming you don't You know break anything and also that you add tests and things like that for that functionality as well So we have kind of a non-traditional Release model or our inclusion model for our branches But it allows us to be a lot more flexible in terms of delivering code to people a lot quicker So 3300 code reviews a lot that means there's a lot of work that's going into the project at a developmental level It means it is very much a very active project in development It takes a lot of time to do those code reviews and a lot of maintenance. So those of you that are developers I would I would urge you to try to participate in that process as well It's a good way to learn the code base if you're not familiar with it and it helps to keep Improving the quality of the submissions and things like that And so I mentioned this already, but Astra 16 was released a few months ago for those that We had not heard it included over a thousand different commits. So that's almost three per day There were of those commits there were 72 distinct or different contributors and Actually now we're up to sixteen dot one dot one. So there's been a few release There's been at least one release major release since then So for those of you who utilize asterisk in production environments Sometimes there are three magical letters that matter that might matter a little bit more to you and those are the letters LTS in asterisk world See those those letters mean different things to different projects But in Astros world that means that you that that branch receives four years of bug fixes and one additional year of security fixes And some of the LTS branches in Astros world are the 11.x major version the 13.x major version and Anyway, so standard releases are shorter there's a year of bug fixes and An additional year of security only fixes and some examples of standard releases in Astros versions are 12.x 14.x and actually 15.x, and you're probably 15 yep 15 is a standard. Okay, so good. I'm glad you brought that up. So I want to talk about this because we so 15 we Made a decision with 15 we made some major changes to the core of 15 including multi-stream video support and multi multimedia stream support for calls and things like that that we wanted to give some more time to bake before we included it in a long-term supported release and so we broke convention so typically the odd numbered releases are LTS's in Astros world historically. That's what they've been But we broke convention and 15 was a standard release instead of an LTS So Anyway, that's that's kind of the background there astros 16 Was things things have gone well with the multi-stream changes. They've been surprisingly stable They've worked very well in terms of our targets and goals with them and from an architectural perspective We felt that they're ready to go in and from stability perspective We felt they're ready to be baked into a long-term release And so 16 actually got graduated into an LTS And so it should be around until at least 2022 and in terms of bug fixes and should receive an additional year of security fixes and die hopefully a quiet death in 2023 So Astros 16 what happened in Astros 16? So I'm actually tons of things happen in Astros 16 a thousand commits My job as project lead is to go through those commits and curate things and try to like fit it into a 20-minute Time period and talk to you about it So I'm gonna talk about flashy things, but there's all you know the new flashiness, right? But there's actually a lot more than what I what I'm talking about that actually happened and occurred So mostly I'm gonna focus on some of the big pushes that we've in terms of big Project-level pushes that we've we've pushed for the last few years and that's a lot in the on the video side of things and Making Astros a better media platform multimedia platform And then we're going to talk a little bit about champ PJ sip as well So in Astros 15 we did a lot as I mentioned we did a lot of work to improve the video We we made the Astros code base suitable to be used in an SFU multi-stream SFU type environment We extended it and it was a lot of fun. It was a lot of work But it seemed like it went well In an effort to get that code out quicker and to make things happen We kind of took a sledgehammer approach in terms of video quality and video packet loss And we what we essentially did was we told the other end if we so for those that aren't familiar with video It's very sensitive to packet loss if you have RTP packet loss You start seeing funny things happen that people freeze or you know if you have video corruption You have like pieces of body parts flying across because the video decoder context. I'm sure many of you've seen that before in different Video applications and things like that, but it's an unpleasant experience And so what astros 15 did to remedy packet loss Situations was it requested a full video frame from the remote end again and kind of a sledgehammer approach which which is suitable but it takes a lot of bandwidth and Sometimes can have latency implications as well And so there are some better technologies to handle that more finer grain technologies to handle that in browsers nowadays And one of those is called a Knack is the knack message our TCP knack message And so we implemented support for knack which is essentially a request for a retransmission of video packet And so that went in and it made a big difference in terms of like how much bandwidth it takes to to fix packet loss and things Things like that There's another technology we added support for which is widely deployed across across browsers called Rembi and it's the receivers So in in video it is the the receivers. I guess it could apply to audio as well, but primarily it was Built out to be used in in video and is used in video, but is the receivers perception of The the local bandwidth that it has right so for example, if you're on a Low bandwidth connection and and somebody's transmitted video and they're in a high bandwidth connection They're sending a mega and a half of video to you and you are received You can only receive 64k of video some teeny tiny stream There is no way that packet retransmission is going to fix that problem because you're in a situation where there's no way to send a Mega and a half stream down a 64 kilobit pipe, right? So in this case this allows the receiver to send the remote end that it's only receiving approximately 64 kilobits It allows the transmitter to change the video encoding rate to be something a lot smaller right to fit in that pipe So it's a good technology, especially when you're you've got heterogeneous networks with different last mile speeds and things like that We added support for what we like to what we called enhanced messaging so As part of the work that we did to build SFU support and asterisk We focused a lot on the multimedia part or the media part of it like the video and the audio and making it all work together and we Added some rest if for those of you familiar with asterisk rest interface for programming programmatically control it We add some some hooks for the multimedia video stuff in the rest API and things like that And then we built our fun engineering prototype. It's not very pretty by the world standards But as engineers that don't do front-end programming. It's it's what we got, right? Patches welcome so We realized that We built out that experience where all those video people were there But we realized that we didn't add API's to be able to correlate those video streams as on the client to like caller ID information or specific participant participant related Metadata or information and so we kind of after we realized that we kind of hit our heads and said oh man How do we miss that? And so we added support to be able to within The conferencing application with asterisk to be able to send participant level information to be able to correlate Okay, this media stream matches up to this participant information this caller ID information maybe this Identification value so you can do lookups and things like that in database and and build rich clients and things like that and so That was one part of it another part was being able to do participant to participant messaging Within the context of that conference bridge as well So if you're building trying to build rich applications on top of the asterisk as a few environment One thing that you're probably want to do is have participants be able to talk to each other In via text or be able to send information back and forth to each other So we added support to be able to bridge Sit messages back and forth between each other between the participants And they can be they can be plain text or you can do like basics for and they can do Any kind of mime type that you can think of and so you can send binary data binary encoded data and things like that as well like if you want to send photographs or images and whatever else you can you can Imagine might fit in your in your application The other thing I want to talk about is PJ sip and performance improvements So for those of you that deploy asterisk, how many of you are familiar with Chen PJ sip? Okay, so not so many hands is before how many of you are familiar with Chen sip Maybe a few more hands. So the history there for those who are not familiar is Chen sip is the legacy sip channel driver We took a step back a few years ago and We realized that Chen sip was getting to the point where from a code-based perspective It was very difficult to make bug fixes and make improvements and things like that We ran the situation where we would fix one bug and we would inadvertently create three more That kind of situation and as developers that that can be very challenging to start from that situation and try to move to a better situation Through through iteration. So what we did is we took a step back and decided to start Take all the things that we learned about sip in the about, you know, 10 to 15 years that we'd we'd Developed on chance it and we built a new chip channel driver using all those lessons that we learned called Chen PJ sip and so Chen PJ sip is the successor to Chen sip if you are building Applications with asterisks that utilize sip Chen PJ sip is the channel driver. You should be using And we want to make sure that there's no good reason that anybody would want to continue to use chan sip So we found at an aster con it was not this last one But the one prior somebody presented a paper or a presentation about chan sip and some there were In most cases chan PJ sip performed better, but there were a couple of cases where Chan sip had a a slight Advantage over chan PJ sip and so we wanted to address those because we have we want We want everybody to use chan PJ sip and like I said have no reason to go back to chan sip and so What we did is we we took that case it was a it was a case of inbound sip registration performance handing handling inbound sip registrations and how many Registrations that it could handle per second and if you look at these two graphs This is the before and this is the after and the the bar in blue that The y-axis is the percentage of CPU utilized so lower is better The the x-axis is the number of registrations sent per second So registration message messages per second if you can have a lower bar that means you're better In previously so the graph on the left. You'll see that chan sip the blue bar had about I mean it looks like about 5 percentage points difference in terms of it was about 5% better in terms of registrations per second all the way up to the 300 registrations per second case If you'll notice on the right after we looked at that and try to fix some things there We we managed to fix that problem and you'll notice now that chan PJ Sips per performs About you know two percent better and some of those two one two three percent better in in that particular use case Now I want to talk about something in these graphs that are You know there's a glaring missing bar on the 350 registrations per second We found out so chan PJ SIP is built in a way to handle multi-chord processors very well to scale across do protocol processing across Multi-chord processors very well We found that chan sip was unable to handle past 300 registrations per second without basically Failing chan PJ SIP was though so 350 so we decided to run some more tests and we found out This is we brought it up to 2,000 registrations per second and we found out with this simple system that we're doing benchmarking on that Again chan sip could not get past 300 registrations per second But chan PJ SIP was able to handle 2,000 registrations per second on this particular system and it probably could have kept going There's still still some more headroom, so There are no good reasons to use chan sip and if you can find one I would love to hear about it because we want to keep making sure that there's no good reason to go back to it I Get I guess going further We actually found some more things that we could do to improve performance in chan PJ SIP and if you'll notice that the delta What before was only a one or two percent two percent difference between chan sip and chan PJ SIP? in 16.1 which is the most recent release of asterisk we we continued to widen that gap And so now it's like three or four percent difference, so we're keep on we're continuing to whittle away on that Anyway, I thought that might be interesting to see So I want to talk a little bit just for a moment about what's happening next so what's happening after 16.0? Well, we've done some work to do more performance improvements You know after you've done a few cycles of major feature editions and things like that like we have for the last few major releases of asterisk It's in a I think inadvertently you always there are some places that maybe you you made performance worse in Different parts and system different use cases and things like that So chat astra 17 is one of our big things that we're going to work on is going back and benchmarking things trying to figure out Where if there are situations where we made things worse in terms of performance and try to continue to improve that try to push push that performance bar We also added some support for those of you that utilize asterisk REST interface to be able to filter events So that your REST applications don't have to receive every single event that comes from asterisk and be able to Have to process each one of those and reduce the load on your REST application and then we also have added so far Some support for doing REST applications without having dial plan as well, and that's actually in a code review That's that's that should be going in probably soon And I think that's pretty much it my time is running short. I had to make this really fast So this is a lot quicker than I usually spend on this But just as a reminder like I said asterisk 14 went end of life In September so if you're on asterisk 14 or utilize Features of asterisk 14. It's a good idea to get off of it and at least move to 15 But even 15 now is in security fix only mode. So 16 might be a good place to to park And so also I would Counsel you for those of you that run asterisk in production or utilize it is keep it You know there is a desire a lot of times to stick to LTS's But it would be a good idea to make sure you keep on top of what's happening in the normal releases as well We generally try to make new releases as of asterisk as boring as possible for users and by boring I mean we try not to break things or surprise you about things, right? There's new functionality we try not to make it so that it regresses the way you you know It impacts the way you use it in an existing way, and it is an extended type experience But sometimes we miss things and so it's always better to catch those things early and report them early While we're still working on them because we're better able to go back and address those things as well And that's pretty much it. Thank you guys very much for your time and for letting me come share with you a little bit about Share with you a little bit about the project