Thirty-Minute Call Drops and One-Way Audio at a Webex Calling Branch
Fabrikam has 300 users at a branch using Webex Calling with a local firewall and SD-WAN. Calls between branch users and PSTN are stable, but calls from branch Webex App users to HQ CUCM endpoints via a CUBE interworking trunk drop at almost exactly 30 minutes. The branch firewall has a 30-minute TCP/UDP session timeout and SIP ALG enabled by default after a firmware upgrade. Users also report one-way audio on about 10% of PSTN calls, mostly after a failover from ISP A to ISP B. Control Hub analytics show MOS 3.3, jitter 38 ms, and packet loss 1.8% on the affected calls; HQ reports MOS 4.2. CUBE is not in the media path for branch-to-branch calls. The SD-WAN policy marks voice EF but does not trust EF from the LAN; ISP B has 90 ms latency and 20 ms jitter.
1. Which symptoms point to the firewall rather than the SD-WAN, and why?
Read the worked answer
The 30-minute drop is almost certainly firewall session timeout, not a Webex Calling limit. The firewall's 30-minute TCP/UDP session timer matches the call duration exactly, while stable calls that are shorter do not drop. SIP ALG makes the one-way audio worse because it rewrites SDP and ports, especially after an ISP failover creates an asymmetric path. The SD-WAN metrics do not explain one-way audio by themselves: 20 ms jitter and 90 ms latency are high but not enough to cause 10% one-way audio; 1.8% loss can hurt MOS but not silence one direction. The branch-to-branch calls are stable because CUBE is not in the media path, which points to the firewall/edge path for the affected calls.
2. How would you prove the firewall cause and remediate the call drops and one-way audio?
Read the worked answer
Disable SIP ALG on the branch firewall and set the UDP session timeout to at least 300 seconds, preferably longer than the longest expected call; for a 30-minute hard limit, increase to 3600 seconds. Capture packets on both sides of the firewall and compare the SDP c= line and m= port; if the firewall rewrites either, ALG is the cause. Check the session table for the 30-minute teardown. After the change, place a 35-minute test call and confirm no drop, then test after an ISP failover. On the SD-WAN side, trust EF from the LAN, apply a voice policy that prefers the lower-jitter ISP, and consider FEC or selective forwarding for ISP B. Monitor Control Hub MOS and packet loss before and after.
3. What SD-WAN policy changes would you make to support stable voice after ISP failover?
Read the worked answer
The SD-WAN policy marks voice EF but does not trust EF from the LAN, so the marking may be stripped or reclassified. Configure trust of EF on the LAN-facing interface and a voice application policy that uses a low-latency path and excludes ISP B when jitter exceeds a threshold. Use per-site application-aware routing and verify with show sdwan app-route or equivalent. If ISP B must be used for redundancy, enable FEC and keep voice on ISP A unless the SLA is breached. Do not rely on oversubscription; reserve bandwidth for voice. After changes, run a week of Control Hub analytics to confirm MOS improves and one-way audio stops.