Forced Authorization Codes and Toll Fraud on Lab Phones
A university runs CUCM with phones in public labs and dorm lobbies. All lab phones share the LAB-PHONES device pool and a line CSS that includes PSTN-LOCAL, PSTN-LD, and PSTN-INTL. Recently, international calls to premium-rate numbers appeared on the bill, and the calls originated from lab phones after hours. The security team wants to block international calls from lab phones except for a small group of administrators, and to block all 900/976 numbers globally. CUCM has a route pattern 9.9011! in the PSTN-INTL partition and 9.900.@ in the PSTN-LD partition. An administrator proposes adding FAC to 9.9011! and creating a translation pattern 9.900.@ with Block in a new BLOCK partition placed first in every CSS. After enabling FAC with authorization level 5 on the route pattern, administrators with FAC codes at level 3 report that their calls fail.
1. Why do the level 3 FAC codes fail after FAC with authorization level 5 was enabled on the route pattern? Explain the FAC validation flow.
Read the worked answer
A FAC code has an authorization level, and the route pattern has a required authorization level. CUCM prompts the caller for the code after the number is dialed, validates the code, and compares the code's level with the route pattern's required level. A level 3 code is below the level 5 requirement, so CUCM rejects the call before routing it, even though the code itself is valid. The fix is either to raise the administrators' codes to level 5 or higher, or to lower the route pattern requirement and restrict who can reach the route pattern by CSS. Raising the code is safer because it preserves the route pattern as the enforcement point. Verify that the FAC codes are in the correct partition and that the route pattern's Require Forced Authorization Code check box is enabled. Also confirm the call is not failing at the gateway for a different reason by checking CUCM traces for the FAC rejection cause.
2. Evaluate the proposed 900/976 block. What traffic would it miss, and how would you make the block complete?
Read the worked answer
The translation pattern 9.900.@ only matches numbers dialed as 9, then 900, then digits. It does not match 9-1-900-NXX-XXXX, 9-011-900..., 9-976..., or 900 numbers reached through a different access code. The route pattern 9.900.@ in PSTN-LD also needs to be considered; if a more specific route exists, the block may not win. A complete block uses translation patterns or route patterns for each dialing form, including 9.1.900.@, 9.1.976.@, 9.011.@ with appropriate filtering, and the direct 900/976 forms. Place the BLOCK partition first in every CSS, including device CSSs and voicemail ports, and test with the actual dial strings. Also restrict the gateway with carrier-level blocking so a CUCM configuration error cannot bypass the block.
3. What else should be done to prevent lab users from bypassing the FAC control through transfer, conference, or call forwarding?
Read the worked answer
FAC is enforced at the route pattern, so any feature that causes a new call to an international number must traverse the same route pattern. Check the CSS used for forwarded calls: the forwarding line's CSS, not the original caller's, is used for the forwarded leg, so a lab line with international access can forward a call to an international number. Block off-net to off-net transfers and conferences with the CUCM service parameters where supported, and remove PSTN-INTL from lab line CSSs entirely if lab users do not need it. Conference and transfer invocations can also use the device CSS, so verify both line and device CSSs. Restrict who can administer phones and FAC codes, and audit CDR for international calls by calling party number rather than relying only on the block.