Specifications
18-35
Cisco Unity Express Voice-Mail and Auto-Attendant CLI Administrator Guide for 3.0 and Later Versions
OL-14010-09
Chapter 18 Configuring Advanced Voice Mail
Configuring Restriction Tables
  • Disable secondary dial tone on voice ports—By default, secondary dial tone is presented on voice 
ports on Cisco router gateways. Use private line automatic ringdown (PLAR) for foreign exchange 
office
 (FXO) ports and direct-inward-dial (DID) for T1/E1 ports to prevent secondary dial tone from 
being presented to inbound callers.
  • Cisco router access control lists (ACLs)—Define ACLs to allow only explicitly valid sources of 
calls to the router or gateway, and therefore to prevent unauthorized Session Initiation Protocol (SIP) 
or H.323 calls from unknown parties to be processed and connected by the router or gateway.
  • Close unused SIP and H.323 ports—If either the SIP or H.323 protocol is not used in your 
deployment, close the associated protocol ports. If a Cisco voice gateway has dial peers configured 
to route calls outbound to the PSTN using either time division multiplex
 (TDM) trunks or IP, close 
the unused H.323 or SIP ports so that calls from unauthorized endpoints cannot connect calls. If the 
protocols are used and the ports must remain open, use ACLs to limit access to legitimate sources.
  • Change SIP port 5060—If SIP is actively used, consider changing the port to something other than 
well-known port 5060.
  • SIP registration—If SIP registration is available on SIP trunks, turn on this feature because it 
provides an extra level of authentication and validation that only legitimate sources can connect 
calls. If it is not available, ensure that the appropriate ACLs are in place.
  • SIP Digest Authentication—If the SIP Digest Authentication feature is available for either 
registrations or invites, turn this feature on because it provides an extra level of authentication and 
validation that only legitimate sources can connect calls.
  • Explicit incoming and outgoing dial peers—Use explicit dial peers to control the types and 
parameters of calls allowed by the router, especially in IP-to-IP connections used on 
Cisco
 Unified CME, Cisco Unified SRST, and Cisco UBE. Incoming dial peers offer additional 
control on the sources of calls, and outgoing dial peers on the destinations. Incoming dial peers are 
always used for calls. If a dial peer is not explicitly defined, the implicit dial peer 0 is used to allow 
all calls.
  • Explicit destination patterns—Use dial peers with more granularity than .T for destination patterns 
to block disallowed off-net call destinations. Use class of restriction (COR) on dial peers with 
specific destination patterns to allow even more granular control of calls to different destinations on 
the PSTN.
  • Translation rules—Use translation rules to manipulate dialed digits before calls connect to the PSTN 
to provide better control over who may dial PSTN destinations. Legitimate users dial an access code 
and an augmented number for PSTN for certain PSTN (for example, international) locations.
  • Tcl and VoiceXML scripts—Attach a Tcl/VoiceXML script to dial peers to do database lookups or 
additional off-router authorization checks to allow or deny call flows based on origination or 
destination numbers. Tcl/VoiceXML scripts can also be used to add a prefix to inbound DID calls. 
If the prefix plus DID matches internal extensions, then the call is completed. Otherwise, a prompt 
can be played to the caller that an invalid number has been dialed.
  • Host name validation—Use the “permit hostname” feature to validate initial SIP Invites that contain 
a fully qualified domain name (FQDN) host name in the Request Uniform Resource Identifier 
(Request URI) against a configured list of legitimate source hostnames.
  • Dynamic Domain Name Service (DNS)—If you are using DNS as the “session target” on dial peers, 
the actual IP address destination of call connections can vary from one call to the next. Use voice 
source groups and ACLs to restrict the valid address ranges expected in DNS responses (which are 
used subsequently for call setup destinations).
For more configuration guidance, see the “Cisco IOS Unified Communications Toll Fraud Prevention” 
paper.










