Inbound calls disconnect at thirty seconds
Tailspin's 800 sales users make and receive calls through Direct Routing with media bypass enabled on the voice route. Since a firewall rule change last Tuesday, roughly 22% of inbound PSTN calls disconnect at almost exactly 30 seconds. Outbound calls are unaffected, Teams-to-Teams calls are fine, and calls that do connect sound good. The SBC vendor's dashboard shows no errors and SIP OPTIONS pings are normal. Users in the same building as the SBC report no problems; users in two branch offices and all remote workers report the issue. Call Analytics shows the failed calls with a system-ended reason and no media quality data.
1. Form a hypothesis and state the single cheapest test that separates the client-side theory from the SBC-side theory.
Read the worked answer
Hypothesis: this is a media bypass failure, not a SIP signalling failure. The evidence aligns:
- Exactly 30 seconds is the signature of a session/media timeout, not of a call that never connected.
- Outbound works. Inbound is affected. With media bypass, the inbound INVITE from the SBC has to reach the client's media candidate directly; if that path is broken, the signalling completes, the call rings and answers, then dies when media never arrives.
- Affected users are exactly those not co-located with the SBC. Users on the SBC's own subnet succeed, which is precisely what bypass failure looks like: the local subnet reaches the SBC because it always did; remote subnets now cannot, because a firewall rule changed the path to the SBC's media ports.
- 'No media quality data' confirms media never flowed on the failed calls.
Cheapest decisive test: take one affected branch user, set the voice route (or the user's policy) to not use media bypass for that user, and place an inbound test call. If the call now survives past 30 seconds, bypass is the cause; if it still drops, look at the SBC/carrier signalling path. This costs one policy change and one phone call, versus days of SBC packet captures.
Confirming checks in parallel: SBC SIP ladder for a failed call (look for re-INVITE/timeout at ~30s rather than a BYE from the carrier), and whether the firewall rule change touched UDP 3478–3481 between client subnets and the SBC, plus the SBC's advertised media candidate addresses.
2. Where do you go for evidence - Call Analytics or Call Quality Dashboard - and what does each one give you that the other cannot?
Read the worked answer
Call Analytics (per user / per call): use it first. It gives a single-call record for a named user within roughly the last 30 days, with the session legs, the media path, whether bypass was used, and the reason the call ended. That is what you need to prove the 30-second pattern on a specific complaint rather than in aggregate. Its limitation is scope: it is one call at a time and only 30 days of history.
Call Quality Dashboard (aggregate): use it to size the problem and to prove the fix. It answers 'how many users, which buildings, since when' - filter on the building/subnet dimension and on whether media bypass was in effect, and watch the poor-call and call-failure ratios by day. It retains data far longer than Call Analytics, so it can show the before/after across the change window. Its limitation is that it will not tell you why one specific call failed.
Practical sequence:
- Call Analytics on two or three reported calls to confirm the failure mode and that bypass was in play.
- CQD filtered to the affected buildings to confirm that the co-located users are genuinely unaffected and that the rate is ~22% rather than, say, 60%.
- After remediation, CQD again - same filters, same dimensions - to show the rate returning to baseline.
Caution: neither tool sees inside the SBC. If both show 'no media', the next artefact is the SBC's own SIP ladder and firewall logs, correlated by call ID and timestamp.
3. Propose the permanent fix and the change-control guardrail that prevents a repeat.
Read the worked answer
Immediate fix: restore the network path required by media bypass - UDP 3478–3481 between client subnets and the SBC's advertised media addresses - and verify the SBC is advertising candidates that branch and remote clients can actually reach. If the firewall team cannot restore the path for all subnets quickly, disable media bypass on the affected voice routes as an interim measure (traffic then flows via the Teams media processor), accepting the added latency, and re-enable it once the path is clean.
Validation:
- Test inbound calls from a branch office, a remote worker, and a co-located user.
- Confirm in Call Analytics that bypass is again in effect and media is flowing.
- Watch CQD for 48 hours; the disconnect rate should return to zero and the poor-call ratio should not regress.
Guardrail: media bypass makes the SBC a media endpoint for the client, so any firewall change touching client subnets must treat the SBC's media ports as business-critical. Add the SBC subnets and the Teams media port range to the change-management impact list, require a Teams voice owner to approve firewall changes that touch those ranges, and keep a standing post-change smoke test: one inbound and one outbound call from each branch office. The failure here was not the firewall rule - it was that nobody owned the call quality impact of a 'network' change.