I85PREP
⌘ K
MS-700 study materials
MS-700 study resources

PSTN for three countries on an existing SBC contract

MS-700 · Put your knowledge to work in context.

All case studies

PSTN for three countries on an existing SBC contract

Northwind has 5,000 Teams users; 1,200 need PSTN dialing. Two certified SBCs run active/active in Chicago and Amsterdam, connected to local carriers under a SIP trunk contract with two years remaining. PSTN users are Chicago 700, Amsterdam 350, Singapore 150. The telephony team has confirmed that Microsoft Calling Plans are available to this tenant only for United States numbers, that carrier numbers exist in Amsterdam and Singapore on the existing trunk contract, and that the carrier will not terminate Singapore emergency calls from an out-of-region SBC - Northwind has no Singapore SBC. Each site needs a main number answered by an auto attendant with an after-hours message and a menu.

1. Recommend the PSTN connectivity model per site and justify each choice against the constraints rather than against vendor preference.

Read the worked answer

Chicago (700 users): Microsoft Calling Plans. They are confirmed available for US numbers, there is no reason to hairpin US domestic calls through an SBC when Microsoft can provide numbers and emergency calling with a registered address, and it removes 700 users' worth of PSTN dependency from the SBC pair.

Amsterdam (350 users): Direct Routing over the existing Amsterdam SBC. Numbers already exist on the trunk contract, the SBC is certified and in-region, and the contract has two years to run - moving to Calling Plans would mean paying twice.

Singapore (150 users): Direct Routing is not available as-is, because the carrier will not accept emergency calls from an out-of-region SBC and there is no Singapore SBC. Options, in order of preference:

  1. Have the carrier provide an in-region SBC / cloud PSTN service for Singapore that peers with Teams Direct Routing (an Operator Connect-style arrangement). This keeps the number range and satisfies regulatory location requirements.
  2. Deploy a small certified SBC pair in Singapore and route Singapore numbers through it.
  3. Interim: route Singapore users through the Amsterdam SBC for business calls only, and document explicitly that emergency calling will not meet Singapore requirements - this needs a written risk acceptance from the business, not an engineering decision.

Key reasoning: the driver is not 'which is cheaper per minute' but number availability, emergency-calling regulatory compliance, and the existing contract. Bandwidth and codec are secondary at this scale.

2. An Amsterdam user dials 020 555 0100. Walk through every component that turns that into a call over the SBC, and say which components you would scope to the Amsterdam site only.

Read the worked answer

Path:

  1. Dial plan + normalization rule. The Amsterdam dial plan holds a normalization rule that matches the local-format number and rewrites it to E.164: +31205550100. Without this, the number is unroutable and the user hears a fast busy or 'cannot be completed'.
  2. Voice routing policy assigned to the user (directly or via group) determines which PSTN usages the user may use.
  3. PSTN usage → voice route. The usage is referenced by a voice route that contains a number pattern matching ^\+31... and points at the Amsterdam SBC trunk (with the Chicago SBC as failover only if your latency and capacity analysis supports it).
  4. Online PSTN gateway / SBC presents the call to the carrier in the format the trunk expects (usually E.164 or a carrier-specific format applied by a further rule).

What to scope to Amsterdam:

  • The dial plan itself (create a site dial plan and assign it, rather than adding Amsterdam rules to the global dial plan) so that local-format rules for one country do not fire for users in another.
  • The voice routing policy with the Netherlands usage, so an Amsterdam user can reach the Netherlands route and a Chicago user cannot accidentally dial out of the Amsterdam trunk.
  • Keep normalization rules for international/emergency dialing in the global dial plan so they apply everywhere.

Test sequence: use the Teams admin center voice routing test / dialed-number test per user, then place a real call to an emergency test number where the carrier supports it, before going live.

3. Design the auto attendant and after-hours experience for each site's main number. What objects and licensing are required, and what is the most common reason this fails on day one?

Read the worked answer

Objects required per main number:

  1. A resource account in Entra ID, created for the auto attendant.
  2. A Teams Phone Resource Account licence on each resource account (it is free, but it is required - this is the most common day-one failure).
  3. A service number assigned to the resource account. For Direct Routing sites, that is an on-premises number assigned to the resource account rather than a Calling Plan number.
  4. The auto attendant itself, with a call flow: greeting, after-hours greeting, menu options, and a directory or operator destination.
  5. Call hours / holiday schedules attached to the auto attendant and to any call queue, so 'after-hours' is defined as data rather than as a static greeting.

Assignments that are easy to miss:

  • The resource account needs a dial plan and voice routing policy assigned, or the auto attendant can receive calls but cannot transfer out or dial back.
  • If the menu transfers to a call queue, the queue also needs its own resource account, licence, and number.
  • For Direct Routing, the number must be assigned consistently on the SBC and in Teams, or the invite arrives with no matching number and the call fails at the trunk.

Most common day-one failure: the resource account exists and the auto attendant is configured, but the licence or number is missing, so calls to the main number ring nowhere or return 'number not in service'. Verify by calling the published main number from a mobile phone, in and out of business hours, before publishing it.