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 <
[email protected]> 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 --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>


-- 

========================================================
Brett Nemeroff
Voice Fox Telephony LLC
Office: 512-670-8369
Email: [email protected]
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- 
[email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the 
sender!

Reply via email to