asked on

unable to make outgoing calls cisco unified communications manager

Good Day Everyone,

I have our CUCM in a test environment associated with a 3845 ISR as the MGCP Voice Gateway. CUCM sees the gateway and the PRI is registered with and backhauled by the CUCM. I have created the following:

Calling Search Space
Partitions
Route Patterns
Route Lists
Route Groups

and assigned everything accordingly per Cisco Documentation.

I am able to make calls on-net, however, when I attempt to make an off-net call I get a busy signal.

I verified that the PRI is active and that the serial interface and protocols are up.

CUCM Version is 8.0.3
3845 IOS is C3845-ADVENTERPRISEK9-M ver. 15.1(1)T (BIN File is c3845-adventerprisek9-mz.151-1.T.bin)

Any help would be greatly appreciated....

Thanks,

David VoiceGW04252011.txt

EyeNoVoIP

when you do a show isdn status do you get multiple frame-established on the PRI? Are you discarding the correct digits on the route patterns? can you do a debug isdn q931 and make some test calls to see if we are getting to the gateway. it is also a good practice to reset the GW via the web interface to make sure all the settings have been applied. you may also bound the mgcp application directly on the router by issuing no mgcp, then mgcp.

Brockstedt

ASKER

I did the checks that you stated Eye, below are the outputs:

I also tried resetting it as you described as well - still no joy.

CpakVGLaGrange#sh isdn status
Global ISDN Switchtype = primary-ni

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply

ISDN Serial0/0/0:23 interface
dsl 0, interface ISDN Switchtype = primary-ni
L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x807FFFFF
Number of L2 Discards = 0, L2 Session ID = 8
Total Allocated ISDN CCBs = 0

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

CpakVGLaGrange#sh logg
Syslog logging: enabled (0 messages dropped, 4 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 397 messages logged, xml disabled,
filtering disabled
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled

No active filter modules.

Trap logging: level informational, 388 message lines logged

Log Buffer (51200 bytes):

000386: *Apr 25 15:53:13.990 EDT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0003
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Net Specific Fac i = 0x00F3
Calling Party Number i = 0x0081, '1072'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '7065809439'
Plan:Unknown, Type:Unknown
000387: *Apr 25 15:53:14.046 EDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8003
Cause i = 0x80B2 - Requested facility not subscribed
000388: *Apr 25 15:53:26.342 EDT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0004
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Net Specific Fac i = 0x00F3
Calling Party Number i = 0x0081, '1072'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '7068837664'
Plan:Unknown, Type:Unknown
000389: *Apr 25 15:53:26.426 EDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8004
Cause i = 0x80B2 - Requested facility not subscribed
000390: *Apr 25 15:53:42.410 EDT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0005
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Net Specific Fac i = 0x00F3
Calling Party Number i = 0x0081, '1072'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '7065809439'
Plan:Unknown, Type:Unknown
000391: *Apr 25 15:53:42.486 EDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8005
Cause i = 0x80B2 - Requested facility not subscribed
000392: *Apr 25 15:53:51.494 EDT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0006
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Net Specific Fac i = 0x00F3
Calling Party Number i = 0x0081, '3795'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '7065809439'
Plan:Unknown, Type:Unknown
000393: *Apr 25 15:53:51.582 EDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8006
Cause i = 0x80B2 - Requested facility not subscribed
CpakVGLaGrange#

EyeNoVoIP

hmm. Is 7065809439 a local or long distance number for your location? This shows that you are sending 10 digits to the telco. Does your telco accept 10 digits for local or do you need to have 11 digits with a leading 1 (one). Or maybe you need to only send 7 digits. How do you have your RP setup and how many digits are you stripping?

Brockstedt

ASKER

Our area requires 10 digits for local calling. I have the route patterns as follows:

9.[2-9]XXXXXXXXX = Local Calling

9.1[2-9]XX[2-9]XXXXXX = Long Distance Calling

The digits being stripped are set as "PreDot"

I did notice in the debugging that the Plan and Type were both set as unknown so I looked on our CME router and they are Pln: ISDN Type: National so I changed this in the CUCM.

Now the error reads as fallows in the debug:

Cause i = 0x80B2 - Requested facility not subscribed

EyeNoVoIP

Ok, typically the Telco will ignore plan and type. I do see that you are only sending 4 digits as your calling number. Please set this to your main number on the PRI. Sometimes the telco will not let you make a call from a number that does not exist on the PRI. This prevents calling number spoofing. Could you please post your CME config so i can do a double check from a working config off of the same PRI? Thanks.

Brockstedt

ASKER

Here is the CME config (Attached) however it uses a different PRI although both PRIs were purchased from same provider.

Once we get the CUCM up and running and tested thouroughly we are going to move everything from the CME to the CUCM.
CME384504252011-2.txt

EyeNoVoIP

thanks, did you try expanding your calling number to 10 digits? Make sure the calling number you choose is a valid number on that PRI. you can also try to use the BTN (Bill To Number) if available. Other than that you will have to open a ticket with your provider and have them do a trace on their end to see where the call is blocked.

If you swap PRI's does the CME fail and the CUCM succeed? I'm assuming these PRI's are in the same trunk group from telco correct?

If that doesn't work can you send a debug isdn q931 from the CME on a successful call?

Brockstedt

ASKER

Gonna have to ask a silly question since this CUCM got dumped in my lap. Where in the CUCM do I set the translation from the extension to a 10 digit number?

In CME I do this in CLI - I am not familiar with this CUCM - am learning this as I go unfortunately.

Brockstedt

ASKER

Here is a successful call from the CME:

Log Buffer (51200 bytes):

007204: Apr 25 18:15:01.721 EDT: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num 7068837664
007205: Apr 25 18:15:01.721 EDT: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0455 callID = 0x83D6 switch = primary-ni interface = User
007206: Apr 25 18:15:01.721 EDT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0455
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Facility i = 0x9F8B0100A118020125020100801044617669642042726F636B7374656474
Protocol Profile = Networking Extensions
0xA118020125020100801044617669642042726F636B7374656474
Component = Invoke component
Invoke Id = 37
Operation = CallingName
Name Presentation Allowed Extended
Name = David Brockstedt
Progress Ind i = 0x8183 - Origination address is non-ISDN
Calling Party Number i = 0x2180, '7068837664'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '7065809439'
Plan:ISDN, Type:National
007207: Apr 25 18:15:02.081 EDT: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8455
Channel ID i = 0xA98397
Exclusive, Channel 23
007208: Apr 25 18:15:04.361 EDT: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x8455
Progress Ind i = 0x8288 - In-band info or appropriate now available
007209: Apr 25 18:15:07.421 EDT: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0455
Cause i = 0x8090 - Normal call clearing
007210: Apr 25 18:15:07.465 EDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x8455
007211: Apr 25 18:15:07.465 EDT: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0455

EyeNoVoIP

There are many places to do this. The easiest right now is to set this on the Route patterns you are using. Under Calling Party Transformations set the Calling Party Transform Mask to the full 10 digit number. This sets it up globally for all calls. Later we can set it up on a phone by phone basis. Let's just get the call working first. Also for right now make sure that the Use Calling Party's External Phone Number Mask is unchecked.

Brockstedt

ASKER

Here is the output from the debug after setting Calling Party Transformation:

001326: *Apr 26 12:42:58.729 EDT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0001
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Net Specific Fac i = 0x00F3
Calling Party Number i = 0x2181, '7062987967'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '7065809439'
Plan:ISDN, Type:National
001327: *Apr 26 12:42:58.833 EDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8001
Cause i = 0x80B2 - Requested facility not subscribed

José Méndez

From Cisco documentation about disconnect cause code 0x80b2:

"The remote equipment supports the supplementary service by subscription only.

This cause indicates that the network cannot provide the supplementary service that the user requests. The user has probably not completed the necessary administrative arrangements with the supporting networks.

The ISDN network can also return this cause code when a user makes a call attempt, but does not enter the SPIDs, or enters the SPIDs incorrectly. Ensure that your SPIDs are correct, or contact your telco to verify your SPIDs.

Also verify the speed of the outgoing call that the ISDN network supports (56k or 64k). "

http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml

Brockstedt

ASKER

Thanks Willy - I had put in a ticket with ITC Deltacom in regards to the error message we received in the output. They are scheduling a tech to see whether the error is on their end or ours.

José Méndez

The only difference I see between good/fail calls, is the facilities subscribed. Can you please tell us the state of the "Send Calling Name In Facility IE" in the PRI configuration page?

Brockstedt

ASKER

It is unchecked

Brockstedt

ASKER

Actually everything under PRI Protocol Type Specific Information for the PRI is unchecked

José Méndez

Check the Route Pattern matched on the affected call. Do you have something under "ISDN Network-Specific Facilities Information Element"?

Brockstedt

ASKER

Network Service Protocol: PRI NI2

Network Service: Foreign Exchange Selection

ASKER CERTIFIED SOLUTION

José Méndez

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Brockstedt

ASKER

Man! Talk about little things that kill.........

Outbound calls work now.

Willy - I really appreciate the time and help you put into this issue.

Thanks - Dave

José Méndez

Glad to hear that.

Brockstedt

ASKER

Eye - I would like to thank you as well for your time and help.

Dave