cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
26794
Views
45
Helpful
6
Comments
Steven Holl
Cisco Employee
Cisco Employee

Contents

Introduction
Prerequisites
       Requirements
       Components Used
       Conventions
Behavior Prior to 15.1(2)T
Behavior With 15.1(2)T and Later Releases

      How to Indentify if TOLLFRAUD_APP is Blocking Your Call
       How to Return to Pre-15.1(2)T Behavior
Contact the Cisco Technical Assistance Center
Related Information


Introduction

A new feature introduced with 15.(1)2T is the default behavior of a toll-fraud prevention feature.

This purpose of this document is to raise awareness of this new feature, as upgrading to this release will require additional configuration to allow for these calls to route.  It is important to note that upgrading to 15.1(2)T will block all inbound VoIP call setups, until the gateway is properly configured to trust these sources.  Hence, any plans to upgrade to releases with this feature must include extra steps to configure trusted VoIP hosts after the upgrade, in order for calls to route successfully.  Additionally, two-stage dialing is no longer enabled by default with this release.

Prerequisites

This document assumes that the reader already has a working knowledge on voice gateway configuration, as well as fundamental knowledge on how to debug voice call failure.

The document discusses configurations that apply to Cisco IOS Voice Gateways, which would include the Integrated Services Routers (ISRs).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Behavior Prior to 15.1(2)T

For all IOS releases prior to 15.1(2)T, the default behavior for IOS voice gateways is to accept call setups from all sources.  As long as voice services are running on the router, the default configuration will treat a call setup from any source IP address as a legitimate and trusted source to set a call up for.

Also, FXO ports and inbound calls on ISDN circuits will present secondary-dial tone for inbound calls, allowing for two-stage dialing.  This assumes a proper inbound dial-peer is being matched.

Behavior With 15.1(2)T and later releases

Upon booting on a version of IOS with the toll-fraud prevention application, the following will be 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   network-mask>]        !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The router will automatically add any destinations that are defined as an ipv4 target in a VoIP dial-peer to the trusted source list.  You can observe this behavior with the output of the following command:

Router# show ip address trusted   list

IP Address Trusted   Authentication

Administration State: UP

Operation State:      UP

IP Address Trusted Call Block   Cause: call-reject (21)

VoIP Dial-peer IPv4 Session   Targets:

Peer Tag        Oper State      Session Target

--------        ----------      --------------

3000            UP              ipv4:203.0.113.100

1001            UP              ipv4:192.0.2.100

How to Identify if TOLLFRAUD_APP is Blocking Your Call

If the TOLLFRAUD_APP is rejecting the call, it will generate a Q.850 disconnect cause value of 21, which represents ‘Call Rejected.’  debug voip ccapi inout can be run to identify the cause value.

Additionally, voice iec syslog can be enabled to further verify if the call failure is a result of the toll-fraud prevention.  This configuration, which is often handy to troubleshoot the origin of failure from a gateway perspective, will print out that the call is being rejected due to toll call fraud.  The CCAPI and Voice IEC output is exemplified in this following debug output:

%VOICE_IEC-3-GW: Application Framework   Core: Internal Error (Toll fraud call   rejected): IEC=1.1.228.3.31.0 on callID 3   GUID=F146D6B0539C11DF800CA596C4C2D7EF
000183: *Apr 30 14:38:57.251: //3/F146D6B0800C/CCAPI/ccCallSetContext:
    Context=0x49EC9978
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"  
000185: *Apr 30 14:38:57.251: //3/F146D6B0800C/CCAPI/ccCallDisconnect:
   
Cause Value=21, Tag=0x0,   Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

The Q.850 disconnect value that is returned for blocked calls can also be changed from the default of 21 with the following command:


voice service voip

ip address trusted call-block cause <q850 cause-code>

How to Return to Pre-15.1(2)T Behavior

I. Source IP Address Trust List

There are three ways to return to the previous behavior of voice gateways before this trusted address toll-fraud prevention feature was implemented.  All of these configurations will require that you are already running 15.1(2)T in order for you to make the configuration change.

1. Explicitly enable those source IP addresses from which you would like to add to the trusted list for legitimate VoIP calls.  Up to 100 entries can be defined.  This below configuration will accept calls from those host 203.0.113.100/32, as well as from the network 192.0.2.0/24.  Call setups from all other hosts will be rejected.  This is the recommended method from a voice security perspective.


voice service voip

  ip address trusted list

  ipv4 203.0.113.100 255.255.255.255

  ipv4 192.0.2.0 255.255.255.0

2. Configure the router to accept incoming call setups from all source IP addresses.

voice service voip

  ip address trusted list

  ipv4 0.0.0.0 0.0.0.0

3. Disable the toll-fraud prevention application completely.

voice service voip

no ip address trusted authenticate

II. Two-Stage Dialing

If two-stage dialing is required, the following can be configured to return behavior to match previous releases.

For inbound ISDN calls:

voice service pots

no direct-inward-dial isdn

For inbound FXO calls:

voice-port <fxo-port>

secondary dialtone

Comments
chrcoope
Level 1
Level 1

Steve,

Thank you. You closed a case today

Chris

Michael Solomonides
Cisco Employee
Cisco Employee

Pre 15.1(2) a similar result can be obtained by using the command

Voice Source-Group name

  Access-list 99

Where access list 99 contains all IP addresses we want to accept calls from.

This command is much less forgiving than the toll fraud app. It prevents the calls from ever reaching CCAPI and does not log any error message when it blocks your call

Cisco SupportForums for post problem that customer experience with Cisco prodect.  As I know you can NOT port a forum at this URL for explan something.   I did samething before and Cisco deleted my ports so why now thy keep it?

kike.delacruz
Community Member

Dear friends

     I would like to confirm some information about this, We had an issue about those Toll Fraud calls, But We realized this

Could you confirm this, specifically here(http://x-ccie.blogspot.mx/2012/05/i-did-upgrade-forthe-ios-of-my-voice.html)

At this part:

Notes:

·   This feature is enabled by default.

·   Duplicate addresses aren't allowed

·   IP address trusted list authentication will be suspended if VGW is registered with GK.

 

So it means the information in bold will be make unavailable the instruction "ip address trusted list authentication"---------no ip address trusted list authentication 

 if a VGW(Cisco VG350) is registered with a GK (Cisco Router 3945)

 

So you have to set the command ip address trusted list authentication to reactivated.???

 

 

 

 

kike.delacruz
Community Member

Dear friends

     I would like to confirm some information about this, We had an issue about those Toll Fraud calls, But We realized this

Could you confirm this, specifically here(http://x-ccie.blogspot.mx/2012/05/i-did-upgrade-forthe-ios-of-my-voice.html)

At this part:

Notes:

·   This feature is enabled by default.

·   Duplicate addresses aren't allowed

·   IP address trusted list authentication will be suspended if VGW is registered with GK.

 

So it means the information in bold will be make unavailable the instruction "ip address trusted list authentication"---------no ip address trusted list authentication 

 if a VGW(Cisco VG350) is registered with a GK (Cisco Router 3945)

 

So you have to set the command ip address trusted list authentication to reactivated.???

 

ivan.garrido
Level 1
Level 1

Hi All,

I am using CME 8.6, with 15.1.4M IOS and IP trusted list for RFC1918. I have a SIP trunk to Elastic for outgoing calls only. I receive SIP setup from other IPs (tollfraud) but CME send this setup to Elastic too...I don't know why..

 

Thanks in advance.

 

Iván.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: