Incorrect caller-id number while calling outbound.

-
We have been allocated three ranges of DIDs corresponding each PRI line
say 0/0/0 for 1XXX, 0/1/0 for 2XXX and 0/0/1 for 3XXX
The way I was using to show the correct DID in outbound calls is via local route group, of course I was using MGCP then.
I recently moved from MGCP to H323 because of its cliched L3 issues causing rigorous call drop.
After this change, I started facing the same issue with calling number again.
Let me summarize here the fix I applied- it might look mussy!

I created three partitions epitomizing my DID range say
pt-1XXX
pt-2XXX
pt-3XXX

Then I copied my route pattern for local/national/international and emergency numbers three times with these partitions like
RP_9.T with pt-1XXX
RP_9.T with pt-2XXX
RP_9.T with pt-3XXX

It will also require route list, corresponding each route pattern.
In this route list, I defined calling number party mask as the full DID and discarding pre-dot digit replacing it with a unique digit.
Like-
RL_1XXX has calling party mask as 8324561XXX with discard per-dot and prefix digit (outbound call) as 2
meaning 9.8324561XXX will be replaced as 28324561XXX

dial-peer voice 208 pots
 description **National outbound calls POTS leg**
 destination-pattern 2T
 direct-inward-dial
 port 0/0/0:15
 forward-digits 11

Create three corresponding CSS as well and allocate it to the users using 1XXX extensions.
CSS-1XXX will contain pt-1XXX
CSS-2XXX will contain pt-2XXX
CSS-3XXX will contain pt-3XXX

This way we are routing the call from the concerned PRI line.

Comments

Post a Comment

Popular posts from this blog

Status: Local Agent is not responding. This may be due to Master or Local Agent being down.

-
If you have read my previous post , you would understand why LA and MA services are important for such a scenario and no component has backed-up, rather you get the above error message. Symptoms -   All Disaster Recovery Framework (DRF) services are down, and no new devices, schedules, or statuses can be viewed from the DRF console. Also, when you access the DRF admin pages, the above error message is received. Affected CM releases 6.1.5 and later. Resolution In order to resolve it, first, verify if the Certificate Serial Number in the keystore of Publisher is present in the Truststore of all Subscribers. Complete these steps: Log on to CUCM OS Administration page of Publisher server of the cluster setup. Choose Security > Certificate Management . The Certificate List window displays. You can use the Find controls in order to filter the certificate. Click on the ipsec.pem file and check the serial number of the certificate. Log on to CUCM OS Administr
Read more

Understanding code yellow

-
Understanding sample code yellow alert- Oct 3 01:00:10, cms01, Error, Cisco CallManager, ccm: 147896: Oct 03 05:00:10.616 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-CodeYellowEntry: CodeYellowEntry Expected Average Delay:362 Entry Latency:20 Exit Latency:8 Sample Size:10 Total Code Yellow Entry:14 High Priority Queue Depth:2 Normal Priority Queue Depth:12 Low Priority Queue Depth:70 Cluster ID:StandAloneCluster Node ID:cms01, 3652 The above alert is about code yellow entry, it shows the time when server enters code yellow state. There are no specifications to note at this alert, CM enters code yellow when it achieves the mentioned conditions for code yellow state as mentioned in service parameters. Oct 3 01:00:12, cms01, Error, Cisco CallManager, ccm: 147897: Oct 03 05:00:12.268 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-CodeYellowExit: CodeYellowExit Expected Average Delay:0 Entry Latency:20 Exit Latency:8 Sample Size:10 Time Spent in Code Yellow:2 Number of Calls Rejected Due to C
Read more