Forum Discussion

Az720's avatar
Az720
Copper Contributor
May 30, 2023

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 SBC itself on TEAMS. LMO and media by pass will be setup on remote site DR SBC.

 

How do you plan to setup this architect?

 

Is it required to setup trunk between Central DR and Remote site DR SBC for call flows to other remote sites?

or

Will call from remote Singapore DR goes to MS TEAMS and then via Central DR SBC reaches to remote Japan DR SBC site?

 

Signaling and RTP for remote sites will be directly between remote DR SBC and MS TEAMS tenant, not via Central SBC if remote site DR SBC will have public IP.

 

What if remote site DR SBC wont have Public IP? How RTP will flow for internal and external callers?

 

Please share your thoughts in case any inputs or thought for this architect.

 

Regards,

Az720

@AudioCodes
@DirectRouting @SBC
@TEAMS

2 Replies

  • Satyamsoft7's avatar
    Satyamsoft7
    Copper Contributor
    Sep 07, 2026

    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.

  • RealTime_M365's avatar
    RealTime_M365
    MVP
    Jun 08, 2023
    Hi,

    This is more complex architecture. Firstly for the remote sites you would need to have the Local Media Optimization done and also the Media Bypass. Additionally you need to ensure that the Local SBC doesn't have a Public IP Address. Local DR Site users will only be able use the services when they are in Office Premises. The services won't work when the users are anywhere else apart from the Office Location.

    Secondly APAC is more complicated because of the Local Telco regulations. If Japan, India and China are three countries in the list I wouldn't even plan for centralized architecture for the same due to complex nature of ever changing local regulations.

    With Regards,
    Satish U