Voice Toll-Fraud Caveats – No VoIP Traffic by Default!

This isn’t exactly the latest news, and doesn’t effect the CCIE Voice Lab exam (although it very well may effect the new CCNP Voice exams), however I am hearing more and more how people are upgrading their Voice routers with newer 15.x IOS code, and not realizing how existing (working) VoIP calls are being broken due to new, intelligent feature default configurations.
Last July, Cisco decided (wisely, IMHO) to create a new style of Toll-Fraud prevention to keep would-be dishonest people from defrauding a company by placing calls through their misconfigured voice gateway(s), at the company’s expense. This new mechanism works by preventing unintended TDM (FXO/CAS/PRI) and VoIP (H.323 & SIP) calls from being able to be placed through a given company’s voice gateway(s), by simply blocking all unknown traffic. Beginning in IOS 15.1(2)T, Cisco added a new application to the default IOS stack of apps that compares all source IP address with an explicitly configured list in the IOS running config, and if the IP address(es) or subnets do not match, all VoIP traffic is denied. Also, the new default for all POTS voice-ports is to not allow secondary dial-tone, making direct-inward-dial the default for CAS/PRI, and PLAR necessary for FXO.

We can trust our VoIP sources with a few, very easy commands.
If we wanted to trust only our CUCM Publisher and Subscribers servers on our GradedLabs Voice Racks, we would add:

voice service voip
  ip address trusted list
    ipv4 177.1.10.10 255.255.255.255
    ipv4 177.1.10.20 255.255.255.255

Or possibly if we wanted to trust the entire subnet that our servers were on, we would add:

voice service voip
  ip address trusted list
    ipv4 177.1.10.0 255.255.255.0

We also have the ability to go back to pre-15.1(2)T behavior by simply doing either this:

voice service voip
  ip address trusted list
    ipv4 0.0.0.0 0.0.0.0

Or this:

voice service voip
  no ip address trusted authenticate

Also, we have the ability to configure the router for pre-15.1(2)T behavior as it relates to inbound POTS calls.
For inbound ISDN calls we would add:

voice service pots
  no direct-inward-dial isdn

And for inbound FXO calls we would add:

voice-port 0/0
 secondary dialtone

One nice thing is that when booting an IOS router with this toll-fraud functionality, a message is displayed on boot-up, letting us know about it – essentially warning us that we need to configure something if we wish VoIP calls to work.
A link to Cisco’s tech note describing this new functionality can be found here.
In summary, when upgrading a previously working H.323 or SIP VoIP gateway to IOS 15.1(2)T or later, until the proper configuration changes have been added to allow the proper VoIP source traffic into your voice gateway, all VoIP calls will cease to function properly. In general, this shouldn’t break FXO/CAS/PRI for most configurations out there – as most folks are likely to have their routers configured properly to handle inbound POTS traffic (i.e. PLAR on their FXO ports and DID on their CAS/PRI port – or so we should hope) – I suppose YMMV depending on each unique configuration.
Let me know if you think this is a good thing that Cisco has done.