A couple of weeks ago a colleague thought it'd be nice to try and run a completely new version of IOS on our test AS5350XM "voice" gateway. It ran without any issues but since the ISDN30 connected to it is hardly used we never really tried to put any calls through it. That is until I had to test some ISDN30 equipment and lacking a PBX the 5350 was the next best thing to test it with.
So I tried to build a SIP > ISDN > SIP path with two ISDN30 gateways back to back. Calling out from the 5350 worked like a charm, but I couldn't get incoming calls towards the gateway to work. I completely redid all the dial peers, number translations, the works. I was completely lost, even turning on debug didn't appear to show any useful info. It matched the correct dial peers but still the calls coming in on the SIP interface were not routed to the ISDN30 interface.
I started spelling every single line of debugging I could enable and got nowhere until I found something like the following:
> 000184: *Apr 30 14:38:57.251: //3/F146D6B0800C/CCAPI/cc_process_call_setup_ind: > CCAPI handed cid 3 with tag 1002 to app "_ManagedAppProcess_TOLLFRAUD_APP"
I knew I hadn't installed this application on the gateway, so where did it come from? I <a href="http://www.google.com/#hl=en&sugexp=ldymls&xhr=t&q=_ManagedAppProcess_TOLLFRAUD_APP&cp=32&pf=p&sclient=psy&site=&source=hp&aq=f&aqi=&aql=&oq=_ManagedAppProcess_TOLLFRAUD_APP&pbx=1&fp=d9008d84f286047">googled</a> for it and found a nice article at the Cisco website called <a href="http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080b3e123.shtml">Toll-Fraud Prevention Feature in IOS Release 15.1(2)T</a>. This article describes how IOS 15.1 will now by default reject all incoming SIP calls until the IP address sending the initial INVITE has been explicitly added as something I'd call a "trusted peer".
One nice piece of wishful thinking from Cisco is this:
> When booting a version of IOS with the toll-fraud prevention application, > this is printed to the device's console during the boot sequence:
Following voice command is enabled: ..voice service voip ....ip address trusted authenticate
The command enables the ip address authentication on incoming H.323 or SIP trunk calls for toll fraud prevention supports.
Please use "show ip address trusted list" command to display a list of valid ip addresses for incoming H.323 or SIP trunk calls.
Additional valid ip addresses can be added via the following command line: ..voice service voip ....ip address trusted list ....ipv4 <ipv4-address> [</ipv4><ipv4 network-mask>] </ipv4>
As if these things all have serial consoles attached to them.
Anyway what's the easiest way to recognize calls being rejected like this?
Logging as mentioned above on the 5350 (or one of its sisters, the 5400, 5800 or any other Cisco "voice" capable hardware
INVITE messages being replied to with a 403 Forbidden with a Reason header containing a "Q.850 disconnect cause value of 21, which represents 'Call Rejected'"