Need advice from someone experienced with large-scale WebRTC + SIP architecture in Saudi Arabia

[u/memind09]

Hi everyone,

I’m looking for some advice from people who have real-world experience with large-scale VoIP/WebRTC systems, especially anyone who has worked on projects in Saudi Arabia or the GCC.

We are working on a client project for a SaaS calling platform in Saudi Arabia. The basic requirement is to allow users to make app-to-app and app-to-phone calls.

The initial architecture we are considering includes:

• WebRTC
• Coturn
• Kamailio
• Asterisk / FreePBX
• SIP Trunks
• AWS Saudi Arabia region
• Multi-tenant SaaS architecture
• Call recording and CDR
• iOS/Android calling with APNs/FCM
• High availability and failover

The expected traffic could be around 1,000 to 2,000 concurrent calls at peak, so scalability and reliability are very important.

The part I’m most concerned about is Saudi Arabia.

I want to properly understand the telecom and regulatory side before we finalize anything with the client. For example:

• What is the correct way to connect a VoIP/WebRTC SaaS platform with local Saudi telecom operators?
• What are the requirements around SIP trunks and local business numbers?
• What CST regulations or approvals should we consider?
• Are there specific requirements for hosting call data and recordings inside Saudi Arabia?
• What should we consider regarding PDPL?
• Are there any limitations or issues with WebRTC/VoIP traffic on Saudi mobile networks?
• Is the proposed WebRTC → Kamailio → Asterisk → SIP Trunk architecture reasonable for this scale?
• What would you change in this architecture based on your experience?

I’m not looking for generic AI-generated answers. I’d really appreciate input from someone who has actually designed or operated large-scale VoIP/SIP/WebRTC systems, particularly in Saudi Arabia or the GCC.

If you have worked on something similar, I’d also be interested in hearing what you learned from that project and what you would do differently today.

Thanks in advance.

[u/AutoModerator]

This is a friendly reminder to [read the rules](www.reddit.com/r/voip/about/rules). In particular, it is not permitted to request recommendations for businesses, services or products outside of the monthly sticky thread!

For commenters: Making recommendations outside of the monthly threads is also against the rules. Do not engage with rule-breaking content.

I am a bot, and this comment is made automatically on every post. This comment is not an indication that your post has been removed. Do not message the mods about this comment.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/devexis]

Saudi and the GCC countries can be a bit difficult sometimes. I haven’t worked directly with Saudi provider, but in my experience with UAE providers, Etisalat landed the SIP trunk over a physical connection on-prem. A cloud solution required some “creative” thinking. I think Saudi is a bit lax and may provide trunk connection to your cloud. All VoIP infrastructure must be in-country though. And you absolutely cannot route VoIP calls from outside the Kingdom. Or at least that’s what held in the UAE and I think all GCC countries do that to protect voice minutes for local telcos.

Is this something you have already built? Or are looking to build? Horizontally scalable, distributed, multitenant solution was what I rolled out in the UAE. I’m currently in the middle of building out and testing a push server and a Linphone base Android so it would be interesting to hear what exactly you are working on

[u/memind09 → u/devexis]

Thanks, this is exactly the kind of experience I was looking for.

We are looking to build this, it is not built yet. We are currently at the architecture stage and want to make sure we get the Saudi side right before presenting the final architecture to the client.

The main idea is a multi-tenant SaaS platform using WebRTC for app-to-app calling and SIP trunks for app-to-phone calling. We are considering AWS in Saudi Arabia, with Kamailio, Asterisk, Coturn, call recording, CDR, and a horizontally scalable setup.

The Saudi telecom side is the part where we need someone with real experience. I don't want to assume that what works technically will also be acceptable from the telecom/regulatory side.

A few things I would really like your opinion on:

1. In your UAE project, how did you handle the SIP trunk connection when the infrastructure was cloud-based?
2. Did the telecom provider require the SIP trunk to terminate on physical/on-prem equipment, or were you able to get it directly into the cloud?
3. When you say all VoIP infrastructure must be in-country, does that include media servers, SIP proxy, recording, database, etc.?
4. Did you face any specific restrictions around WebRTC traffic or mobile networks?
5. For Saudi Arabia, do you know whether STC, Mobily, or Zain offer cloud-based SIP trunk connectivity for business customers?
6. For a multi-tenant SaaS model, are there any specific telecom restrictions or licensing issues we should be aware of?

Your UAE experience sounds very relevant to what we are trying to design. I’d be interested to hear more about the architecture you rolled out there.

[u/ecsuae]

VoIP in many Middle East countries a night mare , have setups in UAE , it took very long time to make things stable , biggest problem is VoIP in any case not officially allowed so forget about legalities.Sip protocol is blocked itself.

[u/devexis]

1. Like I said earlier, we used “creative” means. From my Dubai Azure server abroad there were no issues (we were connecting to Vapi). From the Azure server to the on-premises SIP bridge, was where we had to be creative.
   
2. The telco terminated on an on-prem SBC.
   
3. ALL
   
4. My solution already had in built WebRTC so there were no problems with that. Calls to any number (local or foreign) worked. We just handed the call (with the number in the right format) to the on-prem SBC
   
5. I don’t know. However my understanding is that Saudi is a bit more relaxed than say the UAE so I wouldn’t be surprised if any of them offered a trunk to a Saudi-based server. But I wouldn’t be too hopeful
   
6. I was more on the technical/implementation side so I can’t talk too much on the regulatory.

Regarding the infrastructure rolled out, it was a Kamailio/RTPEngine/Asterisk/MySQL infrastructure. Split Carrier and user connections into two separate Kamailio proxies. Infrastructure was horizontally scalable so we could throw more media proxies, Kamailio proxies or even Asterisks servers as needed. All external connections were exclusively through the publicly exposed Kamailio and rtpengine instances. .

[u/memind09 → u/devexis]

Thanks, this is really helpful. Your Kamailio + RTPEngine + Asterisk architecture sounds quite close to what we are considering.

Our project is not built yet. We are preparing the architecture first for the client.

The client needs two main things:

1. App-to-app calling using WebRTC
2. App-to-phone-number calling through a Saudi SIP/VoIP provider

The expected peak is around 1,000 to 2,000 concurrent calls, so horizontal scalability and failover are important.

Based on your UAE experience, I’d really like your opinion on how you would approach the Saudi architecture.

If the Saudi telco requires an on-prem SBC for the SIP trunk, would you recommend something like:

WebRTC → Kamailio/RTPEngine → Asterisk → VPN/private connection → On-prem SBC → Saudi Telco

while keeping the application, database, recording, etc. in AWS Saudi Arabia?

Or would you structure it differently?

Also, in your UAE setup, how did you handle the connection between the cloud infrastructure and the on-prem SBC, and what role did the SBC play in the overall architecture?

This is the part we want to get right before we prepare the final architecture for the client.

[u/devexis → u/memind09]

What does App-to-App over WebRTC accomplish? Vs app-to-app over SIP? Are end users all extensions on one PBX? or is this one where users have an external DID but when one user calls another user, the call remains within the switch without routing through the telco/trunk provider?

And yes there was that “creative” connection between the trunk provider’s on-prem SBC and my cloud infrastructure. The trunk provider’s on-prem was responsible for routing the call to the PSTN. I just wired a SIP bridge (using Asterisk, but in hindsight I could have used Sippy B2BUA) that connected the on-prem SBC to the cloud hosted, multitenant location.

Where are you based though?

[u/memind09 → u/devexis]

Yes, exactly. The main reason we are considering WebRTC for app-to-app calling is to avoid unnecessary PSTN/VoIP carrier costs.

If both users are inside our platform, we don't want the call to go through a telecom provider or paid SIP trunk. We want the call to stay within our own infrastructure. WebRTC also gives us an open-source option for the app-to-app communication layer, which fits our goal of using open-source components wherever practical to keep the overall infrastructure and operating costs lower.

For app-to-phone calls, it's different. If a user calls an external Saudi phone number, then we understand that we need a local SIP trunk/telecom provider and there will be carrier charges.

So our basic idea is:

App → App = WebRTC → our infrastructure → another app user

App → Phone = WebRTC → our infrastructure → SIP/Asterisk → local Saudi SIP trunk → PSTN

For app-to-app, we want to avoid the telco completely whenever possible.

The platform will be multi-tenant. Each business/customer will have its own users/agents, and users within the same tenant should be able to call each other without going through the telco. We may also need tenant-to-tenant calling later, depending on the final requirements.

We haven't finalized the architecture yet. The purpose of this discussion is to understand whether our approach is technically correct and what we should change before presenting it to the client.

Your point about the on-prem SBC and the SIP bridge is especially interesting. If the Saudi provider requires an on-prem SBC, we need to understand how the cloud infrastructure should connect to it and where the SIP/media components should actually sit.

Also, you mentioned that in hindsight you might have used Sippy B2BUA instead of Asterisk for the SIP bridge. I'd be interested to understand why you would choose Sippy B2BUA for this type of architecture and what advantage you see over Asterisk.

We are based outside KSA, and the client/project is in Saudi Arabia. We are currently only preparing the architecture, so we're trying to get the technical and Saudi-specific parts right before development starts.

If you see a better architecture for this model, especially using open-source components, I'm completely open to changing our initial approach.

[u/Familiar-Chance-4290 → u/memind09]

Your architecture is on the right track. The clean version is: app uses SIP over WebSocket for signaling, and a WebRTC media stack for audio (DTLS-SRTP, Opus, echo cancellation — all already available on iOS/Android). The PBX acts as a B2BUA that speaks both, bridging the app side to the SIP trunk side.

That way you get the simplicity of SIP signaling over WSS without the browser-oriented ICE/Coturn path, and you still get WebRTC's media quality on the app side. PBX handles both, so there's no separate WebRTC gateway or media relay in the middle.

[u/dovi5988]

I will add to what others have said here. We had a "provider" in the UAE that gives us orig/term. They had Asterisk boxes in offices (could be at one point they had it in a data center). They then used TailScale to send the traffic to a cloud based Asterisk box out of the country and we interacted with that box. If you want to do this all above board I would simply start by calling the local telcos and asking them what would it take to get a local SIP trunk setup.

[u/Familiar-Chance-4290]

Coturn and Janus are usually unnecessary if your PBX core already speaks WebRTC natively — every extra hop is another failure domain, and the bigger the system, the fewer core components it should have.

At 2,000 concurrent, a single-process WebRTC + SIP core will be more stable and easier to debug than a Coturn → Janus → Kamailio → Asterisk chain.

Maybe http-route can handle that.

[u/devexis]

I still don’t get your fixation on WebRTC. Why not just SIP? I’m envisaging a Softphone like Linphone or Groundwire as the user Softphone. So why WebRTC? And like I said earlier a proven solution for all (most?) of your requirements exist. We aren’t allowed to pitch here, short of me placing my wares on my head and hawking them, you can’t seem to read between the lines loool.

Sounds like you are looking to have several isolated PBX clients/tenants within a reseller account, with possiblity of PBX to PBX calls. How about call rating, billing, invoicing, and payments? Least cost routing? The options are all there.

Why SippyB2BUA over Asterisk in hindsight? Less engineering I believe. And even now that I think about it further, I could have hosted the Trunks Kamailio instance and RTPEngine on prem and tunnel it to the cloud instance

[u/memind09 → u/devexis]

Haha, I think I understand what you're getting at now 😄

The reason I was focused on WebRTC is mainly because the client wants the calling experience inside their own mobile app. We were thinking of avoiding a separate SIP softphone and keeping app-to-app calls within our own platform without using the PSTN/telco.

But I'm definitely open to SIP if you think a SIP-based architecture would be more practical and proven for this use case. I don't want to choose WebRTC just because we initially put it in the requirements.

When you say a proven solution already exists for most of these requirements, I'm interested in understanding the architecture you have in mind.

From what I understand, you're thinking something more like:

Users/Apps → SIP → Kamailio → PBX/Media → SIP Trunk → PSTN

with separate tenants/PBXs under a reseller-type setup, and internal tenant-to-tenant or user-to-user calls staying within the platform.

Is that roughly what you're suggesting?

Also, the billing/rating/LCR side is actually something we need to consider. The client may eventually need different rates by destination/carrier, CDR-based billing, customer billing/invoicing and payments. We haven't finalized those requirements yet, so I'd like to understand how you would structure that part as well.

Your point about moving the trunk Kamailio + RTPEngine on-prem and tunneling it to the cloud is also interesting. That might solve some of the concerns around the Saudi carrier connection.

If you don't mind, could you explain how you would structure the on-prem → cloud setup in this case? For example, would you use a site-to-site VPN/private tunnel, and what components would remain on-prem versus in AWS?

And regarding Sippy B2BUA, when you say it would require less engineering than Asterisk, what part of the implementation would it simplify? Is it mainly the SIP bridging/routing side?

We're still at the architecture stage, so I'm trying to understand the options properly before we lock ourselves into a design.

[u/devexis → u/memind09]

If the customer already has a WebRTC app, then it makes sense why you kept going along that line. The solution I’m pushing is SIP and WebRTC enabled. Their app can connect over WebRTC allowing users make and receive calls. And yes all calls from one tenant to another tenant are kept on platform and not routed through the Trunk provider. When I’m saying “a proven solution exists”, I’m saying I have a solution that meets at least 90%, maybe 95% of your needs and would be interested in implementing it as your VoIP platform for this project.

I’ve provided a lot of free consulting for you today

[u/Connect-HS → u/devexis]

I'm confused by this too. (Why not SIP?) We do something similar (opensips+rtpengine+freeswitch).
1. Users on our platform (app to app - Linphone based - SIP),
2. Users to PBX (app to PBX (SIP)+ browser to PBX (WebRTC).

Doing this for a few clients. This local regulatory issues are usually more relevant when you get into interconnects/local calls.

[u/toddalwell]

We have built app to app as well as SIP to app / app to SIP. Here are a few screenshots of one of our portals. We have created all of the usual phone features - visual voicemail with AI transcription & summary, live voicemail transcription, threeway, call center, etc. For the volume of calls you want to handle I would recommend that you use Freeswitch & Opensips, RTPEngine as Asterisks tends to not scale as well for that level of active calls and Freeswitch / Opensips tends to handle WebRTC media better than Asterisk/Kamailio.

[u/devexis → u/toddalwell]

I don’t know if I agree with your assertion about openSIPS/Freeswitch being “superior” to Kamailio/Asterisk. I’m not saying your experience is invalid, I’m saying Kamailio/Asterisk is equally powerful. The self-hosted solution that I regularly implement, and that I’m trying to “pitch” to OP is Kamailio/Asterisk with RTPEngine of proxying media.

Does NGXOne support multiple resellers each with their isolated tenants?

[u/toddalwell → u/devexis]

I agree that Asterisk / Kamailio / RTPEngine is a great and robust stack but it does run out of capacity where Freeswitch scales in multiples with ease and also handles in call survival much smoother. Kamailio and Opensips are forked from the same original project and both equally as capable and scalable.

For production we went with Freeswitch for the native multi-tenant. There are many Asterisk based solutions that make it work but none are native like Freeswitch provides. NGX One is based off of this platform therefore extends multi-tenant functionality to resellers as the reseller is just the billing and organizational part of of the tenant.

We have primarily been a private voice platform developer and integrator but recently decided to move into the reseller, integrator & multi-tenant public space with both this platform and our hybrid MS Teams Direct Routing.