In our case, we've managed to turn Asterisk into a Docker container, so we can scale up/out as much as needed.
Interestingly, after running about 500 containers in production (500 asterisk instances) we've found that there's a lot of untapped power in the smaller containers, so we ended up designing our PBX web portal and our dial plan to be multi-tenant. So, effectively, we can stick about 20 customers (roughly 100 to 400 SIP endpoints total) on a single Asterisk docker container without breaking a sweat. The main issue now is trying to filter the real-time console output - We don't give customers access to any of that of course, just filtered logs and events via our web portal, which is permissions-based - so that a technician can diagnose a possible call flow failure without having to grep through tons of information. Luke Escudé Owner, CEO 972.600.1150 supp...@primevox.net Schedule a meeting!<https://outlook.office365.com/owa/calendar/primevoxcommunicati...@primevox.net/bookings/> View the PrimeVOX R&D Roadmap here<https://trello.com/b/pzpoyn8m/primevox-engineering> View the PrimeVOX Status Page here<https://status.primevox.net/> ________________________________ From: Jaco Kroon <j...@uls.co.za> Sent: Wednesday, January 18, 2023 1:31 AM To: Asterisk Developers Mailing List <asterisk-dev@lists.digium.com>; Luke Escudé <l...@primevox.net> Subject: Re: [asterisk-dev] Logging and multi-tenancy Hi Luke, On 2022/12/23 18:48, Luke Escudé wrote: So, it's possible to achieve multi-tenancy in Asterisk with well-designed dial plan. By multi-tenancy, in terms of Asterisk, I mean each "customer" has their own separate dial plan, and each customer cannot "see" another. As long as each "customer" has their own "endpoint" details (for whatever protocol they use to connect), yes, this is technically possible. There are other risks associated, eg, if you give them access to AMI or even to the CLI ... how do you control data visibility? This just gets very, very risky. Given that a well tuned asterisk instance can use sub 100MB of RAM ... I don't see the problem with running an asterisk instance per tenant. Eliminates most of the above concerns, and if you do it right, pretty much all of the issues just goes away. The one serious downside is that you need to bind each one to a different IP ... which is also not a major problem, one idea around this is to use a SIP proxy to dispatch to the correct "private" IP based on the registered to realm. However, when it comes to looking at the asterisk CLI/console, you see all the calls flowing across all dial plans, which can be a lot to look at. Correct. What is the possibility of adding some kind of "tenancy filtering" to CLI logging? Extremely unlikely. Example: At the beginning of a dial plan call, let's say exten => s, we set LoggingTenancy(customer_id), then all of the subsequent log messages are visible in the CLI only if you run the "logging view tenant (x)" or something like this. That would make it easier to diagnose call issues on high-volume systems. Agreed. We generally use the full log. So in logger.conf: full => notice,warning,error,debug,verbose(4),dtmf,fax Now each call will have a C-?????? tag associated with it. So after the call has completed, find the C-????? tag (You can for example use your LoggingTenancy idea here, but something like Verbose(TENTANT=?????, CLI=${CALLERID(full}, DST=${EXTEN}) - this will give you something to grep for in the full log to find C-??????, then grep C-?????? full. I, personally, do not have the ability to implement this, but I wanted to put it out there. Luke Escudé 972.600.1150 supp...@primevox.net<mailto:supp...@primevox.net> Schedule a meeting!<https://outlook.office365.com/owa/calendar/primevoxcommunicati...@primevox.net/bookings/> View the PrimeVOX R&D Roadmap here<https://trello.com/b/pzpoyn8m/primevox-engineering> View the PrimeVOX Status Page here<https://status.primevox.net/>
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
