Dear all,
I hope this email finds you well. I am reaching out to gather insights and suggestions regarding a potential redesign of our VoIP system to improve scalability, ease of management, and upgradeability. *Current Setup:*
- Our system is *not multi-tenant* and is based on *Kamailio and FreeSWITCH* in a distributed architecture (as example of distributed architecture, see: https://ufdcimages.uflib.ufl.edu/UF/E0/04/92/89/00001/THOMPSON_C.pdf). - Everything runs inside *LXC containers* across multiple nodes. - One of the challenges we face is *OS upgrades*, which are cumbersome and require significant manual intervention. - At the moment the code for voip is done with ansible
Given these challenges, I am considering whether a *microservices-based architecture* could be a viable option. However, I have some concerns regarding:
- *SIP and RTP handling with NATed containers* (e.g., Kubernetes, Docker Swarm) and potential issues with media traversal. - *Performance impact* when shifting real-time traffic handling to containerized environments. - *Upgrade and deployment strategies*—how to achieve smoother, rolling upgrades without service interruptions. - *Alternative approaches* that might be more effective, such as a hybrid model combining LXC with containerized microservices for specific functions.
If anyone has experience transitioning a VoIP system to microservices or has insights on best practices for *scalable, maintainable VoIP architectures*, I would greatly appreciate your thoughts. What worked for you? What pitfalls should we be aware of?Do you have any documentation that I can check?
Looking forward to learning from your experiences. Thank you.
.: Francesco Colista
.: Francesco Colista
I think there is a tendency to get fancy with these kinds of implementations. Do you really need to be able to dynamically scale services? Or can you just use a load balancer and a collection of servers you roll in and out of service as you need? That's what I've done. I've also used a sort of outbound proxy (or multiples) so that the source IP going out is from a small collection of proxies. The inner routing servers become a sort of dynamic pool and their IPs don't really matter.
Of course,this is specific to the implementations I've worked on. Your specific needs may dictate something else.
I personally wouldn't add the complexity of k8s because I simply don't change that much that frequently.
-Brett
On Tue, Mar 25, 2025 at 11:17 AM Francesco via sr-users < sr-users@lists.kamailio.org> wrote:
Dear all,
I hope this email finds you well. I am reaching out to gather insights and suggestions regarding a potential redesign of our VoIP system to improve scalability, ease of management, and upgradeability. *Current Setup:*
- Our system is *not multi-tenant* and is based on *Kamailio and
FreeSWITCH* in a distributed architecture (as example of distributed architecture, see: https://ufdcimages.uflib.ufl.edu/UF/E0/04/92/89/00001/THOMPSON_C.pdf).
- Everything runs inside *LXC containers* across multiple nodes.
- One of the challenges we face is *OS upgrades*, which are cumbersome
and require significant manual intervention.
- At the moment the code for voip is done with ansible
Given these challenges, I am considering whether a *microservices-based architecture* could be a viable option. However, I have some concerns regarding:
- *SIP and RTP handling with NATed containers* (e.g., Kubernetes,
Docker Swarm) and potential issues with media traversal.
- *Performance impact* when shifting real-time traffic handling to
containerized environments.
- *Upgrade and deployment strategies*—how to achieve smoother, rolling
upgrades without service interruptions.
- *Alternative approaches* that might be more effective, such as a
hybrid model combining LXC with containerized microservices for specific functions.
If anyone has experience transitioning a VoIP system to microservices or has insights on best practices for *scalable, maintainable VoIP architectures*, I would greatly appreciate your thoughts. What worked for you? What pitfalls should we be aware of?Do you have any documentation that I can check?
Looking forward to learning from your experiences. Thank you.
.: Francesco Colista
.: Francesco Colista
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hello Francesco,
I agree with Brett, be wary of fashion fades.
Voip is """" just """" routing around packets, by inspecting and modifying them
This needs to be completely aware of all states of all things (transactions, dialogs, application, user, billing, cdr, etc) at all moments for all calls (and if you need to land specific calls on specific media boxes - eg freeswitches - then you need even to know the relashionships between an incoming call and all the legs already in the whole platform)
On top of that, there are all the particularity of using real time streaming in udp, instead of a transactional query/answer model like db or http (and smtp, etc)
So, all in all, for the core part of voip, you are well served by kamailio+freeswitch
You may want to optimize it, but that is the way it has to be
Obviously, the applications on the back of voip can be refactored (or completely rewritten) to be microservices (the GUIs, the CRMs, etc) if there's gain in doing that
Have a great day!!
answered from mobile, please pardon terseness and typos, -giovanni
On Tue, Mar 25, 2025, 17:44 Francesco via sr-users < sr-users@lists.kamailio.org> wrote:
Dear all,
I hope this email finds you well. I am reaching out to gather insights and suggestions regarding a potential redesign of our VoIP system to improve scalability, ease of management, and upgradeability. *Current Setup:*
- Our system is *not multi-tenant* and is based on *Kamailio and
FreeSWITCH* in a distributed architecture (as example of distributed architecture, see: https://ufdcimages.uflib.ufl.edu/UF/E0/04/92/89/00001/THOMPSON_C.pdf).
- Everything runs inside *LXC containers* across multiple nodes.
- One of the challenges we face is *OS upgrades*, which are cumbersome
and require significant manual intervention.
- At the moment the code for voip is done with ansible
Given these challenges, I am considering whether a *microservices-based architecture* could be a viable option. However, I have some concerns regarding:
- *SIP and RTP handling with NATed containers* (e.g., Kubernetes,
Docker Swarm) and potential issues with media traversal.
- *Performance impact* when shifting real-time traffic handling to
containerized environments.
- *Upgrade and deployment strategies*—how to achieve smoother, rolling
upgrades without service interruptions.
- *Alternative approaches* that might be more effective, such as a
hybrid model combining LXC with containerized microservices for specific functions.
If anyone has experience transitioning a VoIP system to microservices or has insights on best practices for *scalable, maintainable VoIP architectures*, I would greatly appreciate your thoughts. What worked for you? What pitfalls should we be aware of?Do you have any documentation that I can check?
Looking forward to learning from your experiences. Thank you.
.: Francesco Colista
.: Francesco Colista
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-
Brett Nemeroff -
Francesco -
Giovanni Maruzzelli