Configure and Troubleshoot Call

Forward to the PSTN using

SIP Trunks
Introduction

With the increased usage of mobility features and work from home scenarios, there is increased
demand for the ability to transfer incoming calls from the PSTN back out to different PSTN
destinations. When using SIP trunks for PSTN connectivity these calling scenarios often fail due to
call validation. This document is a guide to configuration and troubleshooting of these call flows.

Core Issue

All outbound PSTN SIP calls are validated by the SIP Trunk provider to ensure the calls are valid and
not toll fraud attempts. The methods of call validation can vary from provider to provider, and
many involve multiple methods for the same call. This becomes a concern when using the default
settings in a CUCM w/CUBE topology and attempting to call forward an inbound PSTN call back out
to the PSTN. One of the most common validation methods is for the SIP provider to examine the
From field in the incoming INVITE of a call and make sure it matches to a known DID number for
that customer. The default setting in CUCM for forwarding calls is to maintain the CLID of the
calling originator. This causes the From field of an outgoing INVITE to contain the CLID number of
the original PSTN caller, and not a valid DID belonging to the customer. When the provider sees this
with no additional information, it typically will reject the call setup attempt or ignore it completely.

Resolution

There are three common solutions to this issue.

The first is to alter the From field so that the CUCM will send the information of the redirecting
number instead of the call originator. In this scenario the From field will contain a valid customer
DID number, and the call will validate. The advantage of this technique is that it works with

virtually all SIP providers. The disadvantage is that the receiving party of the forwarded call will
only see the caller-ID of the number that was set to forward (typically their own office DID number).
They will not see the caller-ID of the original caller, and therefore will not know who is calling prior
to answering the call.

1 Here are the steps to use the first method:

-Navigate to the SIP Trunk page in CUCM

-Navigate to Outbound Calls section of the page
-Change the value in the drop down entitled Calling Party Selection to Last Redirect Number
(External)
-Save the change, and apply the change (may drop calls why you press apply, so be careful with
this change during business hours)

A second method is also often used, though it requires the SIP provider to validate calls through a
different method. This technique involves adding a p-asserted identity line in the outbound INVITE
containing a valid DID. The advantage of this technique is that the From field retains the calling
originators information so that the recipient of the call can see who is calling on their caller-ID. The
disadvantage of this technique is that it is not universally used, and customers need to check with
their SIP providers to make sure they will validate calls based on the p-asserted identity value
instead of the from field value.

2 Here are the steps to use the second technique when using a CUBE gateway:

-Log into the CUBE router

-Add the following SIP profile (make sure to use a unique profile number if you have existing SIP
profiles, or add it to your outbound SIP profile in use. Also make sure to use a valid DID number and
SBC URL information.)

voice class sip-profiles 1

request INVITE sip-header P-Asserted-Identity add P-Asserted
Identity:<sip:1111111111@sbc.sipprovider.com>
-Add the following configuration line to the dial-peer being matched to place the outbound call to
the SIP provider:

voice-class sip profiles 1

Make sure that the SIP Profile contains a valid DID with your SIP provider. Also, most providers will
look for a fully qualified domain name in the PAI, as opposed to an IP address. Be use to use the
FQDN in the profile, even if you are routing the calls directly to the providers IP address.

The third method is similar to the second but instead of a PAI line, this uses a Diversion Header.
The Diversion Header is added to the outbound INVITE and contains a DID number that the
provider can validate the call with. Like with the second option, the advantage of this technique is
that the From field retains the calling originators information so that the recipient of the call can
see who is calling on their caller-ID. The disadvantage of this technique is that it is not universally
used, and customers need to check with their SIP providers to make sure they will validate calls
based on the diversion header value instead of the from field value.

3 Here are the steps to use the third technique when using a CUBE gateway:

-Navigate to SIP Trunk page in CUCM

-Navigate to Outbound Calls section of the page
-Check the Redirecting Diversion Header Delivery Outbound Check box
-Save the change, and apply the change (may drop calls why you press apply, so be careful with
this change during business hours)
-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing SIP
profiles, or add it to your outbound SIP profile in use. Also make sure to use a valid DID number and
SBC URL information.)

voice class sip-profiles 1

request INVITE sip-header Diversion modify <sip:(.*)@(.*)>
<sip:1111111111@sbc.sipprovider.com>
-Add the following configuration line to the dial-peer being matched to place the outbound call to
the SIP provider:

voice-class sip profiles 1

Make sure that the SIP Profile contains a valid DID with your SIP provider. Also, most providers will
look for a fully qualified domain name in the diversion header, as opposed to an IP address. Be use
to use the FQDN in the profile, even if you are routing the calls directly to the providers IP address.

Troubleshooting

The following debugs are useful in this call scenario:

debug ccsip messages

debug voip ccapi inout

When reading these debugs keeping the different call legs straight can get confusing. It is
recommended to use an application such as Notepad ++, and to mark the Call ID of each call leg
traversing the CUBE. The goal of these debugs is to check that the outbound INVITE for the
forwarded call contains either the correct from field, or the correct p-asserted identity or
diversion header field. If using the from field method, check that the SIP INVITE coming from
the CUCM contains the full 10 digit DID number for the last redirecting party, and that this value is
the same in the INVITE going to the provider. If using either the p-asserted identity method or the
diversion header method, make sure that the outgoing call is matching the correct dial-peer that
has the voice-class sip profile set on it. If it is matching a different dial-peer, add the sip profile to
that dial-peer.

Call Forward All (offnet to offnet not working)

Hi dears,

i am facing issue related to Call forward all

We have SIP (283XXXX) and E1 trunk (494XXXX)
I am trying CFA on cisco 7911 and providing mobile as destination.
I am using user profile to login on the phone for SIP and E1 DIDs
For SIP when dial DID number from my mobile; it show me message "invalid number" on my
mobile
For E1 when i dial DID number from my mobile; it process sometime and say "your call can't
be completed as dialed". I can see the logs on gateway for the destination number and
matching dial peer also
Note: I give CFA CSS the same i gave to the line. Also "block offnet to offnet" service
parameters is "false".
This issue only for offnet to offnet call.
Simple incoming and outgoing call have no problem with SIP or E1.
ANSWER:
========
Hi,
From the logs

++++++

Sent:

INVITE sip:0501029946@10.200.7.157:5060 SIP/2.0

Via: SIP/2.0/UDP 10.66.7.126:5060;branch=z9hG4bK3EF6E20F
Remote-Party-ID:
<sip:28300582210218@10.66.7.126>;party=calling;screen=yes;privacy=off

++++++
It appears that the calling number "28300582210218" is not part of your DDI.
To resolve this go to your sip trunk>outbound calls>calling party selection>choose: First
redirect number (external)..Then reset the trunk, test again and post debug ccsip messages
if it doesn't work

Outbound Caller ID issue using CUCM 8.6,MGCP gateway & PRI lines
Hi,
We have two DID range from our service provider: 02825911XX & 02829212XX
02825911XX maps to extension 11XX
02829212XX maps to extension 12XX.
We have 2 E1 lines 60 Channels.
Current setup:
CUCM (8.6.2) <----MGCP----> Gateway (2921) <======2 E1=====> Carrier/ Teleco.
Issue:
When calling from 11XX we are getting correct caller id 02825911XX.
But when calling from 12XX we are getting caller ID 02825911XX instead of 02829212XX.
eg: when calling from 1206 far end caller id shows 0282591106 instead of 0282921206.
There is no issue in incoming calls on both the ranges.

The external mask are correctly configured under the DN.

The debug ISDN q931 shows the correct caller id till the gateway:

ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x016A

Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98396
Exclusive, Channel 22
Display i = 'test'
Calling Party Number i = 0x0081, '0282921206'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '82353587'
Plan:Unknown, Type:Unknown
Attaching ccapi inout & isdn q931 debug. & Gateway config.

Hello Gyanendra,

I have checked the debug and gateway configuration.

These debug are taken from gateway. The gateway shows TX- Setup. Once we have sent
setup information to Telco, I don't think we can change the calling ID information. This
means that we are sending correct calling party number information to Telco(0282921206).
May be Telco is changing the calling party number on their own? Have you checked with
Telco as yet? If no, ask them what's the calling party number they are getting. You can do a
live test and trace same call with Telco engineer.

The trace log details:

Sep 10 00:49:25.410: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x016A

Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98396
Exclusive, Channel 22

Display i = 'Ludvik Aunedi'

Calling Party Number i = 0x0081, '0282921206'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '82353587'
Plan:Unknown, Type:Unknown
Sep 10 00:49:26.222: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x816A
Channel ID i = 0xA98396
Exclusive, Channel 22
Sep 10 00:49:26.222: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x816A
Sep 10 00:49:26.258: //6444/9E3008C18C96/CCAPI/ccCallModifyExtended:
Nominator=0x2B305B60, Params=0x2B304D78, Call Id=6444
Sep 10 00:49:26.258: //6445/9E3008C18C96/CCAPI/ccCallModify:
Nominator=0x18E30, Params=0x2B304F80, Call Id=6445
Sep 10 00:49:26.258: //6444/9E3008C18C96/CCAPI/cc_api_call_modify_done:
Result=0, Interface=0x2AF52C6C, Call Id=6444
Sep 10 00:49:26.262: //6445/9E3008C18C96/CCAPI/cc_api_call_modify_done:
Result=0, Interface=0x2AD55F80, Call Id=6445
Sep 10 00:49:29.406: //6444/9E3008C18C96/CCAPI/cc_handle_inter_digit_timer:
Generate inter-digit timeout CC_EV_CALL_DIGIT_END event
Sep 10 00:49:35.262: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x816A
Sep 10 00:49:35.266: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref
= 0x016A
Also, can you do another test call and attach:
debug mgcp packet along with debug isdn q931 and CCAPI inout
Regards,
Amarjeet

Thank you guys the issue was with carrier/teleco end. They hadn't actually enable the 2nd
range form line perspective & had NATL configed for 2 digits. We are now going to ask them
to change it to NATL 6 Digits.

How to change the caller ID display from one

number to another and the external phone
number mask is configured but does not work
properly

Core Issue
The caller ID that needs to be displayed is not the extension, but the main office number.
Entering the desired phone number in the external phone number mask and rebooting the
phone does not affect the displayed caller ID.

Resolution
In order to resolve this issue, you can use these locations in the CallManager Administration
to configure caller ID:

Directory Number Configuration page Scroll down to External Phone Number

Mask and enter the number that you want to send to the PSTN. Then click Update at the
top of the page. You have to repeat this same procedure for the other extensions
configured for this IP phone (if you want to send those numbers to the PSTN).

Route Pattern Configuration page Locate the route pattern that you are using to
make calls to the PSTN. Scroll down to the Calling Party Transformations section.
o

If you check Use Calling Party's External Phone Number Mask, you use
the number that you configured in the Directory Number Configuration page as the
caller ID.

If you uncheck Use Calling Party's External Phone Number Mask, then
you can configure the Calling Party Transform Mask. Enter a number such
as 978858xxxx (CallManager fills out the xxxx with the phone's 4-digit extension).

Route List Detail Configuration page Go to the Calling Party

Transformations section.

Use Calling Party's External Phone Number Mask If you set this to On, you use
the number that you configured in the Directory Number Configuration page as the caller
ID. If you set it to Off, then you need to configure the Calling Party Transform
Mask (next line on this same page). The setting that you use here overrides the settings
that you configured in the Route Pattern Configuration page. You configure the Calling
Party Transform Mask here in the same way as explained for the Route Pattern
Configuration page.
For more information, refer to these documents:

Understanding and Troubleshooting Call Routing and Dial Pattern Problems with
Cisco CallManager

Configuring Route Patterns

Route List

CUBE - New Deployment Issue - No media after

HoldResume
Hello,
Scheme:
Cisco SCCP-based IP Phone > CUCM 9.1 w/ SIP Trunk > CUBE (28XX, 151-4.M7) > SIP ITSP
CUCM Active Call Proc. Node IP: 10.10.10.9
CUBE Inside Interface IP: 10.10.10.10
CUBE Outside Interface IP: 20.20.20.20
Cisco IP Phone: 10.10.10.8
ITSP SBC IP: 30.30.30.30 [sbc.itsp.domain]
ITSP SIP domain: itsp.domain
Calling Pty: 9017654321 (translated in CUCM's route pattern which addresses CUBE)
Called Pty: 9011234567

Symptom:
After outbound call is connected calling party (IP Phone) place call on hold.
Then after resume there is no audio for both sides (call remains active) although before hold
all was fine.
Thoughts:
None.
Question:
Please, advice, how this can be fixed.

To understand where the problem is occurring we need to understand how call-hold/resume

work in SIP with CUCM/CUBE. Here are the steps that happens when a call is put on hold or
transferred.
1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in
media path
2. CUCM sends a Delayed offer to insert MOH or to resume Media stream
3. CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive
offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path

remains in an inactive state and causes calls to drop call will drop)
4. CUCM sends an ACK with sendonly to the 200 OK
5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to
MOH (in attempt to ocmplete transfer)
6. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends
200 OK with the required SDP to connect the call
++++Here is the analysis of your logs++++
Here is a DO re-invite to CUBE to insert MOH, which CUBE sent to your ITSP (step 2
above)
Received:
INVITE sip:00019011234567@10.10.10.10:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.9:5060;branch=z9hG4bKf317a71eccad9
From: <sip:79017654321@10.10.10.9>;tag=1230280~e7a88f34-6357-445a-a3f40cff26e7d816-35401728
To: <sip:00019011234567@10.10.10.10>;tag=1652C7D4-16EC
Date: Tue, 10 Feb 2015 16:34:49 GMT
Call-ID: aace2d80-4da13310-c6e1c-15520c0a@10.10.10.9
+++Here is CUBE sending out the DO to ITSP+++++
Sent:
INVITE sip:79011234567@30.30.30.30:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 20.20.20.20:5060;branch=z9hG4bKD61EBD
From: <sip:79017654321@itsp.domain>;tag=1652C61C-1A26
To: <sip:79011234567@itsp.domain>;tag=986B324631353641C1A16100
Date: Tue, 10 Feb 2015 16:34:49 GMT
Call-ID: 821C33E4-B07911E4-82F1E759-B8B0000E@20.20.20.20
++++Here is the 200 OK from your ITSP (this is step 3 above, ITSP needs to send a sendrecv)++++
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 20.20.20.20:5060;branch=z9hG4bKD61EBD
From: <sip:79017654321@itsp.domain>;tag=1652C61C-1A26
To: <sip:79011234567@itsp.domain>;tag=986B324631353641C1A16100
Call-ID: 821C33E4-B07911E4-82F1E759-B8B0000E@20.20.20.20
-c=IN IP4 30.30.30.30
t=0 0
m=audio 10320 RTP/AVP 8
b=AS:64
a=inactive
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:20
++++++++
As you can see ITSP is sending a=inactive, Hence the call is unable to resume as the media
path remain inactive.
Suggestions/Solutions

1. We can try a feature called mid-call INVITE/Update consumption. With this feature the reINVITE is not sent to ITSP by CUBE and hopefully this should resolve it. To configure this do
the following
voice service voip
sip
mid-call signaling passthru media-change
2. You can also use MTP required on the sip trunk. This will also stop the re-INVITE going
out to your ITSP. This should be the last resort though!

After I've checked 'Media Termination Point Required' under CUCM's CUBE trunk all is
working.
The only strange things are the following:
1. I do not have CUBE XCD registered with CUCM, only with itself. I mean CUCM
theoretically cannot access this media resource.
2. I monitor via RTMT performance counters that non CUBE software MTP (IP VMS based)
is not utilized at all.
3. I see that XCD is utilized per sucessfull call as xcode resource while both of legs are using
g711a.
The situation when it's not clear why it is working but the fact is operable is all right :)

Early Offer send SDP at INVITE msg to ITSP

CUCM -->> Cisco GW(Router) -->> SIP Service Provider

I have to cinfigure SDP Early offer as per std from my SP and Codec as G711-alaw 1
preference, G711-ulaw 2 preference.

I guess your question is how to configure Early Offer for SIP-ITSP on Router as well as on
the CCM < > Router (CUBE) SIP Trunk.

For the CUBE, you may invoke Early Offer either globally or on the dial-peer by the following
commands:

1. For Global
Router(config)#voice service voip
Router(conf-voi-serv)#sip
Router(conf-serv-sip)#early-offer forced
Router(conf-serv-sip)#

2. For Dial-Peer
Router(config)#dial-peer voice 200
Router(config-dial-peer)#voice-class sip early-offer forced

For CCM , it is under the SIP Trunk - Profile Configuration under the following:
"Early Offer support for voice and video calls (insert MTP if needed)"

MTP Required

SIP Early Offer Support over Unified CM SIP Trunks

SIP negotiates media exchange by means of the Session Description Protocol (SDP), where one
side offers a set of capabilities to which the other side answers, thus converging on a set of media
characteristics. SIP allows the initial offer to be sent either by the caller in the initial INVITE
message (Early Offer) or, if the caller chooses not to, the called party can send the initial offer in
the first reliable response (Delayed Offer).
By default, Unified CM SIP trunks send the INVITE without an initial offer (Delayed Offer). In
general SIP Delayed Offer is preferred for Unified CM SIP trunks because MTPs are not needed
to establish a Delayed Offer call for voice, video, or encrypted media. If SIP Early Offer is desired,
Unified CM has two configurable options to enable a SIP trunk to send the offer in the INVITE:

Media Termination Point Required

Enabling the Media Termination Point Required option on the SIP trunk assigns an MTP
from the trunks media resources group (MRG) to every outbound call. This statically assigned
MTP supports only the G.711 or G.729 codecs, thus limiting media to voice calls only

Early Offer Support for Voice and Video Calls (Insert MTP If Needed) (Starting with CUCM 8.5)

When Unified CM receives an inbound call on an H.323 Slow Start or SIP Delayed
Offer trunk, the media capabilities of the calling device are not available when the
call is initiated. In this case, Unified CM must insert an MTP and will use its IP address and
UDP port number to advertise all supported audio codecs (after region pair filtering) in the Offer
SDP of the initial INVITE sent over the outbound SIP trunk.

When the Answer SDP is received on the SIP trunk, if it contains a codec that is supported by the
calling endpoint, then no additional offer-answer transaction is needed. In case of codec
mismatch, Unified CM can either insert a transcoder to address the mismatch or send a
reINVITE or UPDATE to trigger media negotiation. Calls from H.323 Slow Start or SIP Delayed
Offer trunks support audio only in the initial call setup, but they can be escalated mid-call to
support video and SRTP if the call media is renegotiated (for example, after Hold/Resume).

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/trunks.html#wp1123289

Use the following steps to determine whether MTP resources are required for your SIP trunks.
o

o
o
o

The far-end SIP device defined by this SIP trunk capable of accepting an inbound call
with SIP delayed offer then no MTP require for outbound calls, Else we need to allocate MTP
resources to support outbound early offer calls. The outbound early offer calls will only supported
for G711 codec.
The only case where MTP is required is when one of the endpoints supports out-of-band
only and the other supports NTE only. This is applicable with conference bridges, CTI route
points for IVR also.
If you want to force on SIP Trunk to use RFC 2833 DTMF method, and then
we have to allocate MTP for DTMF conversion for sccp phones.
MTP also require for H323 fast start outbound calls, not require for fast start inbound
calls

MTP Configuration option at SIP trunk

Select a Trunk DTMF Signaling Method, which controls the behavior of DTMF selection on that
trunk. Available MTPs will be allocated based on the requirements for matching DTMF methods
for all calls.
a. DTMF Signaling Method: No Preference
o
o

In this mode, Unified CM attempts to minimize the usage of MTP by selecting the most
appropriate DTMF signaling method.
If both endpoints support NTE, then no MTP is required.
If both devices support any out-of-band DTMF mechanism, then Unified CM will use KPML over
the SIP trunk. F
b. DTMF Signaling Method: RFC 2833
By placing a restriction on the DTMF signaling method across the trunk, Unified CM is forced to
allocate an MTP if any one or both the endpoints do not support NTE.
c. DTMF Signaling Method: OOB and RFC 2833
In this mode, the SIP trunk signals both KPML and NTE-based DTMF across the trunk, and it is
the most intensive MTP usage mode. The only cases where MTP resources will not be required is
when both endpoints support both NTE and any OOB DTMF method (KPML or SCCP).

MTP and DTMF relay on H323 trunk

The following scenarios can occur when two endpoints on different clusters are connected with
an H.323 trunk:
o

When both endpoints are SIP, then NTE is used. No MTP is required for DTMF.

o
o

When one endpoint is SIP and supports both KPML and NTE, but the other endpoint is
not SIP, then DTMF is sent as KPML from the SIP endpoint to Unified CM, and H.245 is used on
the trunk. No MTP is required for DTMF.
If one endpoint is SIP and supports only NTE but the other is not SIP, then H.245 is used
on the trunk. An available MTP is allocated for the call. The MTP will be allocated on the
Unified CM cluster where the SIP endpoint is located

Do I need MTP or Transcoder?

MTP only
o
o
o
o
o
o

Terminate media stream (of same codec)

Transrating of media resources(20 ms to 30ms)
H323 Fast start(only need if CUCM initiate outbound FS call) not for slow start
SIP early offer(only need if CUCM initiates outbound EO call) not for incoming call
DTMF relay Conversion (SIP notify -RTP NTE)
CUCM 8.5 doesnt require MTP for SIP early offer

How to troubleshoot CDR when getting the error

message: (CDR Error:10021)

Checking current configuration

Run the following command:
"run sql car select * from car:tbl_system_preferences"
-(This command will show you the current configuration on the Publisher for the CDR
service)
Example:
admin:run sql car select * from car:tbl_system_preferences
param_name param_value
========================= ========================================
MIN_DATE 11/09/2014
MAX_DATE 01/06/2015
LAST_PROCESSING_DIRECTORY
CDR_MIN_DATE 11/09/2014

MAX_CDR_NUMBER 2000000
MAX_ERROR_RECORD_ID 191255
COMPANY_NAME
TOLL_FREE 1800,1855,1866,1877,1888
CHARGELIMIT 200.00
GOOD 20.00
POOR 30.00
DEFAULT_CAR_USER _unspecifieduser
LOADER_STATUS 1
CONTINUOUS_LOADING_24_7 1
LOAD_CDR_ONLY 1
MANUAL_PURGE_STATUS 0
LOADER_SCHEDULE_BACKUP DailyCdrLoad,L,1440,-1,00:00:00,0,300,30
PURGE_LOW_WATER_MARK 80
PURGE_HIGH_WATER_MARK 90
MIN_CAR_DATABASE_AGE 2
MAX_CAR_DATABASE_AGE 60
LAST_PROCESSING_FILE
LAST_PROCESSING_DATA_ROW
CDR_MAX_DATE 01/06/2015
UPDATE_STATISTICS_DATE 01/06/2015,0
LOADER_BATCH 600,600,2500,3000
HUNTPILOT_VALUE 1
TIMEZONE_FOR_CDRSEARCH 2
CCM_SERVERNAME cvxs_1_cm_ccm10_5_1_11900_13
INSTALLATION_DATE 11/13/2011

Restoring CDR tables back to default

(Publisher)
-Those commands will recreate the CDR data base tables back to the default state. Please
follow them in the order they are shown up.
run sql car update tbl_system_preferences set param_value='2000000' where
param_name='MAX_CDR_NUMBER'
run sql car update tbl_system_preferences set param_value=' ' where
param_name='COMPANY_NAME'
run sql car update tbl_system_preferences set
param_value='1800,1855,1866,1877,1888' where param_name='TOLL_FREE'
run sql car update tbl_system_preferences set param_value='200.00' where
param_name='CHARGELIMIT'
run sql car update tbl_system_preferences set param_value='20.00' where
param_name='GOOD'
run sql car update tbl_system_preferences set param_value='30.00' where
param_name='POOR'
run sql car update tbl_system_preferences set param_value='_unspecifieduser' where

param_name='DEFAULT_CAR_USER'
run sql car update tbl_system_preferences set param_value=' ' where
param_name='LOADER_SCHEDULE_BACKUP'
********************************************************************************************
Some times you will see that the Min date and Max date are not correct as the
following output shows:
=========================================
MIN_DATE
02/11/2015
MAX_DATE
02/12/2015
CDR_MIN_DATE
02/11/2015
CDR_MAX_DATE
02/12/2015
MAX_CDR_NUMBER
2000000
MAX_ERROR_RECORD_ID
119561992
COMPANY_NAME
TOLL_FREE
1800,1855,1866,1877,1888
CHARGELIMIT
200.00
GOOD
20.00
POOR
30.00
DEFAULT_CAR_USER
_unspecifieduser
LOADER_STATUS
1
CONTINUOUS_LOADING_24_7 1
LOAD_CDR_ONLY
1
MANUAL_PURGE_STATUS
0
LOADER_SCHEDULE_BACKUP DailyCdrLoad,L,1440,-1,09:07:00,0,0,1440
PURGE_LOW_WATER_MARK
80
PURGE_HIGH_WATER_MARK 90
MIN_CAR_DATABASE_AGE
2
MAX_CAR_DATABASE_AGE
60
LAST_PROCESSING_DATA_ROW 600
LAST_PROCESSING_FILE
cdr_NDCCucmCluster_02_201502121818_169247
LAST_PROCESSING_DIRECTORY 20150212
UPDATE_STATISTICS_DATE 02/13/2015,0
LOADER_BATCH
600,600,2500,3000
HUNTPILOT_VALUE
1
TIMEZONE_FOR_CDRSEARCH 1
CCM_SERVERNAME
xnzxpap210x_ccm8_6_2_24901_1
INSTALLATION_DATE
10/3/2012
********************************************************************
-Make sure to set up the MAX_DATE being today and the MIN_DATE being one of two
month ago using the following commands:
run sql car update tbl_system_preferences set param_value = '12/17/2014' where
param_name = 'MIN_DATE'
run sql car update tbl_system_preferences set param_value = '12/17/2014' where

param_name = 'CDR_MIN_DATE'
run sql car update tbl_system_preferences set param_value = '02/13/2015' where
param_name = 'MAX_DATE'
run sql car update tbl_system_preferences set param_value = '02/13/2015' where
param_name = 'CDR_MAX_DATE'
After doing that you need to follow the next steps:
Restart services in the following order
1-Go ahead and complete a manual purge on the CDR web page.
Cisco Unified Serviceability-->Tool-->CDR Analisis and reporting-->System-->Data Base->Manual purge-->Purge.
2-Make sure that the Service Parameter CDR flag is "True"
3-Cisco CAR Web Service "Restart"
4-Cisco CAR Scheduler "Restart"
5-Cisco CDR repositiry Manager "Restart"
6-Cisco CDR Agent "Restart"

********************************************************************************************

Make a test call and get the call records

needed
After following the steps above you will be ready to place a test call and use the CDR
analysis and reporting tool to find the records that customer needs.
Enjoy it!