Forum Discussion
Audio Codes Distributed Direct routing Architect strategy
Hi Community, I would like to discuss about the design and architect behind setting up distributed DR SBC. Plan: A Central DR in a APAC region, all other APAC PSTN sites will be setup as DR S...
For multi-site APAC Direct Routing with AudioCodes, think in two planes: Teams signaling/media to each site SBC, and optional site-to-site SIP only when you need PSTN hairpin without Teams in the middle.
If each remote site SBC has a public FQDN registered in Teams (and Media Bypass / LMO enabled correctly):
- Signaling and media for that site’s users go site SBC ↔ Microsoft, not via the central APAC SBC.
- You do not need a trunk between Singapore and Japan SBCs for normal Teams↔PSTN at each site.
- Central SBC is useful as another regional gateway, for shared carrier capacity, or as a fallback—not as a mandatory media hub for every remote site.
When a remote site has no public IP:
- Media Bypass/LMO usually cannot land media on that site SBC. Options are: public media interface (or static NAT done right), keep media through Microsoft (bypass off), or anchor via a public central/proxy SBC—with the latency and capacity tradeoffs that implies.
- LMO vs Media Bypass naming matters: LMO is the multi-SBC / proxy-SBC pattern; plain Media Bypass is “client can reach this SBC’s media.” Mixing them without matching proxy/derived-trunk design is a common failure mode.
I wrote the Media Bypass vs LMO split (when each helps and when it bites) here: https://skypeexchange4u.com/media-bypass-vs-local-media-optimization/
If you can say whether Japan/Singapore will each have public SBC media, the “trunk between sites?” question becomes a clear yes/no.