Opening Matt Fredrickson - asterisk project lead
we want to make sure to thank you by having a lunch that is catered, there is some drinks & breakfasts available.
so lots of ways to prevent your blood suagar from dropping
thanks for E4 stratiges for lunch that helps us a lot
also of note we are ending at 15h, that is atypical due to conflicting obligations like a panel
Eric - when will pictures happen
Answer - we will wait until lunchtime
lunch is in the national ballroom B (accross the way)
We do have a speakerphone available & a wireless network called asteriskdevcon that should be more reliable than the astricon wifi
Password is the same digium18
Also want to thank Torrey for taking notes day and George for setting up streaming for those who cannot participate onsite. The development process is bigger than any one room
Introductions:
Matt Fredrickson - sangoma
Torrey Searle - Voxbone
Malcom Davenport - digium - product manager - here for free food
Jared Smith - digium
cristophe durieux - connect with the community
Claude Paltry - jive
Jroan - sipgate - bulding a new infrastructure in ast16 with ari
david duffet - digium - observing
fred posner - lod - interestin in the future of asterisk
Ludovic gasc - allo cloud -belgium - interested in ari
pascal cadotte - wazzo - in quebec in future development esp ari
evan boily - wazzo - hope next astricon will be in canada - interested in futre of asterisk
egar ventruovsky - russia - IQ tech unistim developer
Nir Simovitch - isreal - clodonix - uncarrier - here for fun
Eric Klein - clondonix - sponsoring dangerous demos
Lenz Dimitiri - lowe in switserland
Sean McCord - psycore systems - atlanta
Dan Jenkins - nimble ape UK - here to be quiet
andrew naggy - socal - sangoma
james benstrup - writes bugs for freepbx
brian walters - sangoma - buffalo ny - interested in future of asterisk
Jason Parker - atlanta -sangoma - work on phones for sangoma
Dan Collins - usain - knocksville
Paulo Vicentini - Brazil - Voxbone - help with ast13 rollout
Steve Murphy - next vortex - wyoming -
Peter Weschke - see where asterisk is going with ari
harrison schults - corona - indianapolis
john harden
alex goodman - corona
ben ford - digium - working on ast for 1 year
kevin hartwell -alabama - digium - getting feedback
alejandro traud - frankfurt germany - unemploied - used ast for 6 years
George Joseph - digium developer
What ever direction you like to see asterisk is within your power.
What has happened in this last year:
asterisk 15.x 6 bug fix releases, current is 15.6.1
asterisk 14 8 security releases last version is 14.7.7
asterisk 13.x 6 bug fix releases current 13.23.1
3300 merged code reviews (across all branches)
it is amazing the number of contributions, that is a pretty amazing number
that is also means alot of eyeballs, people helping wiht review is strongly encouraged, there are alot of patches pending review a long time because of lack of reviews
1000 commits on asterisk 16 (close 3 per day) 72 individual contributing
asterisk 16 as been released! it has been in feature freeze already for a while. if you haven't tested it yet, then well patches welcome 
Top contributor
260 Corey Farrel
Standard release vs LTS
something happened last here that broke convention, that made some people angry
in asterisk land we have 2 categories of releases, one is the standard release and the other is the magic LTS
alot of people feel confort in LTS, we decided in lots of caution due to the lots of changes in ast 15 especially ref multi-stream support
we decided not to make 15 an tls, which broke lots of conventions. On the other hand the changes were supprisingly stable. they maintained compatiblity with most of the applicaiton interfaces
Standard release
1 year bug fix, 1 year security fix
LTS
4 year bug fix, 1 year security fix
additionaly we have a new branch inclusion policy. new features can be put into an existing branch so long as there are tested and are non-major nor breaking changes
that allowed us to alot of neat things with that especially in branch 13, and it helps other branches because all those tests can get moved to the other branches as well
it has been a few years since the last LTS. 16 will be an lts, will be around until 2022, and security fixes til 2023
What's new in 16?
Webrtc video
webrtc api
chan_pjsip performance
misc fun
Improving video resilance
- sensitive to packet loss
- a loss of a single frame - strange things happen
- in ast 15 we took a sledge happer approach, if we detected packet loss we requested a full new video frame, (sending an entire video frame uncompressed, -very wasteful)
- we knew there were some better tech, but didn't have time to use them
- one tech is NACK - an RTCP control message
- rtcp is the protocol used in accompanment of rtp, sends statistics
- the decided to extend rtcp to do other things to allow other things, including NACK
- it is a negative acknowledgement
- so if a packet is lost, you send a nack to inform of the lost packet and sender will retransmit, allowing stream repair
Remb
- bandwith estimation
- informs of sender of bandwith limitaitons (I only detect 1.5mb of video, please limit)
- instant packet repair problem
- negotiated in sdp (nack is as well)
Enhanced Messaging:
Backround - updated all apis to have multiple audio/video streams
last year it looked like people in boxes ( it was a really big deal)
there is some metadata, local video description, remote video description
how on earth do I figure out that is kevin karwell and write in on his box
we added an api to correlate callerid streams with participant metadata
additionally we thought it would be good to add participant to participant messaging to confbridge
allows a one stop shop solution, or to keep messaging close the the media path
uses in-dialog sip MESSAGE, you can set the content type, but only use UTF-8
George did alot of work on the conference bridge, don't want to take away his thunder
PJSIP performace improvements
good talk ref chan_sip vs pjsip last year, large attendence room was packed. in alot of cases chan_pjsip performed better, but some cases it did not
however not a considerable difference, but we still wanted to address them
approx 7% in cpu usage worse in reg handling
after some perfomance improvements we now have chan_pjsip perform better than chan_sip, 2k req/s for chan_pjsip vs 300 for chan_sip
Misc fun
build improvements: DragonFly BSD, NetBSD, OpenBSD, Solaris 11, FreeBSD
I'm a linux guy so I always fall into the trap of thinking that Linux is the only *nix out there, but Alexander Traud contributed alot for building for other platforms
IPV6 added for Dundi
Does anybody use Dundi? (not that you shouldn't be useing it but it often gets forgoten about)
pjproject updated to v2.8
ability to bundle build libjansson, some versions of jansson have bugs, so bundling helps
misc gccc bug fixes
enhanced messaging with app_sendtext
new databuffer api added to the internal core api of asterisk, allows to do things like packet retransmisison buffers
early media video support in app_dial
python3 compatibility fixes - test suite is largely written in python, and different supporiting scripts
if you are a python developer we would love to see some help in reviewing those scripts to geting them compatible with python 3
sean bright worked on ephemeral DTLS certificates saves alot of pain of cert generation
support for a new cdr backend called beanstalk, developed by Nir
started looking into performance bottlenecks in stasis message buss, (it's a pubsub message buss)
improvements to strictrtp - the way we live in a world that is outside the standards of the RFCs, nat is a reality and part of the challenges are that, in sdp there is an address it expects to recieve media on. In order to work in that world you have to believe that address. If the other end is a private ip address that isn't true. some of the things that are done are symmetricip, where asterisk sends rtp back to the same address it recieved on, this is all find, but it has to trust the rtp stream is the right stream. But this can lead to hijacking of rtp streams.
Strict rtp is on by default, prevents of rtp hijacking can't happen, it may cause limitations when lots of video streams are happening, or crappy networks that send packets in big clumps, that presented problems in strictrtp, some improvements were added to make that better.
Reminder ast14 went EOL a couple weeks ago. Ast15 graduated to security fixes only mode. Keep track of what's happening in non-lts major releases of asterisk.
keep a test environment with non-lts releases to avoid supprises,
ast17 is presumably a standard relase so good opportunity to start breaking things