Long distance dialing from CUCM

bkhanal1971 · ‎01-24-2013

I have noticed that I am not required to prefix 1 anymore to dial the national long distance numbers from my UCM 8.6 environment. Earlier, if I forgot to prefix 1, a message would prompt me to dial 1 before the number to proceed with the call but now I no longer have to dial 1 before the number to reach any long distance numbers. Is it new thing in the carrier side or something is not configured right in my CUCM. There are no digit manipulations for called number in the CUCM side, not even digit stripping. Only place where digits are manipulated are in the h.323 gateway. Even in the gateway, all I see is that the outside access code of 8 (we use 8 instead of 9 due to massive 911 miscalls) is stripped.

We use client matter code (CMC) for call accounting purpose and all long distance calls should be accounted. Local 10 digit calls do not require CMC code for it to proceed. Since we are not required to prefix 1 for the long distance calls, when somebody makes such calls, they are not prompted for the code. I am finding it difficult to pin point what/where things went wrong.

Thanks

Chris Deren · ‎01-24-2013

This has nothing to do with CUCM version and strictly a telco thing. Can you post the GW config and "debug isdn q931" if this is a PRI, if not PRI let us know the circuit type.

Chris

bkhanal1971 · ‎01-24-2013

Here is the debug isdn q931 output and dial peers. Yes it is a ISDN PRI circuit.

1. Call from DC to NY goes through without 1

Gateway#debug isdn q931

Jan 24 23:35:11.422: ISDN Se0/0/1:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 13

Jan 24 23:35:11.422: ISDN Se0/0/1:23 Q931: Sending SETUP callref = 0x06AE callID = 0x85B1 switch = primary-ni interface = User

Jan 24 23:35:11.422: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8 callref = 0x06AE

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98396

Exclusive, Channel 22

Calling Party Number i = 0x2181, '2028848000'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '2122431110'

Plan:ISDN, Type:National

Jan 24 23:35:11.538: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x86AE

Channel ID i = 0xA98396

Exclusive, Channel 22

Jan 24 23:35:13.090: ISDN Se0/0/1:23 Q931: RX <- ALERTING pd = 8 callref = 0x86AE

Progress Ind i = 0x8088 - In-band info or appropriate now available

Jan 24 23:35:13.538: ISDN Se0/0/1:23 Q931: RX <- CONNECT pd = 8 callref = 0x86AE

Jan 24 23:35:13.538: %ISDN-6-CONNECT: Interface Serial0/0/1:21 is now connected to 2122431110 N/A

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

2. Call from DC to NY goes through with prefix 1

Jan 24 23:36:32.934: ISDN Se0/0/1:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 13

Jan 24 23:36:32.934: ISDN Se0/0/1:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num 2028848000

Jan 24 23:36:32.938: ISDN Se0/0/1:23 Q931: Sending SETUP callref = 0x06B0 callID = 0x85B3 switch = primary-ni interface = User

Jan 24 23:36:32.938: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8 callref = 0x06B0

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98396

Exclusive, Channel 22

Calling Party Number i = 0x2181, '2028848000'

Plan:ISDN, Type:National

Called Party Number i = 0x80, '12122431110'

Plan:Unknown, Type:Unknown

Jan 24 23:36:33.038: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x86B0

Channel ID i = 0xA98396

Exclusive, Channel 22

Jan 24 23:36:34.738: ISDN Se0/0/1:23 Q931: RX <- ALERTING pd = 8 callref = 0x86B0

Progress Ind i = 0x8088 - In-band info or appropriate now available

Jan 24 23:36:35.138: ISDN Se0/0/1:23 Q931: RX <- CONNECT pd = 8 callref = 0x86B0

Jan 24 23:36:35.138: %ISDN-6-CONNECT: Interface Serial0/0/1:21 is now connected to 12122431110 N/A

Jan 24 23:36:35.138: ISDN Se0/0/1:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x06B0

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

Dial-peers pertinent to the calls. There is only one translation rule for modifying ANI and no other translation rules exist.

dial-peer voice 13 pots

trunkgroup PSTN

description ROUTE.LOCAL.CALLS.TO.PSTN

translation-profile outgoing 1

destination-pattern 8[2-9].........

forward-digits 10

!

dial-peer voice 14 pots

trunkgroup PSTN

description ROUTE.LONG.DISTANCE.CALLS.TO.PSTN

translation-profile outgoing 1

destination-pattern 81[2-9]..[2-9]......

forward-digits 11

When checked in DNA, calls are using the right Pattern, CSS, RL and SLRG.

Thank you,

sumitkum · ‎01-24-2013

Hi

Kindly send the translation rule configuration and ISDN PRI configuration. also confirm that the number u dailed with and without prefix is reached to same destination.

Chris Deren · ‎01-24-2013

It sure looks like telco is letting you make these calls, is this MEGACOM trunk by any chance? Could be because they see it as ISDN Type National and handle it properly. Your best bet would be to contact telco to see why that is, if you feel this is a problem for you.

HTH,

Chris

bkhanal1971 · ‎01-24-2013

Thank you Chris. I am relieved with your findings as I was begining to worry if I messed up something in the configuration in the UCM or gateway. I will contact Level 3 (our telco provider) to fix it unless they charge us flat rate for both local and long distance numbers. In the worst case, I may have to create a bunch of route patterns for long distance numbers with CMC requirements.

Thank you again.