cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
667
Views
0
Helpful
10
Replies

CALLER ID

ali
Level 1
Level 1

Would someone tell me how to enable the outbound Caller ID on CCM ver 3.0(7).

Thanks,

10 Replies 10

dgoodwin
Cisco Employee
Cisco Employee

You need to be more specific. What kind of gateway are you using, and what type of voice connection does it have to the PSTN or PBX?

Cisco DT-24+ Gateway and a PRI to the PSTN.

dgoodwin
Cisco Employee
Cisco Employee

Please set the CallManager trace level to DETAILED, make a call through the gateway, go to the CCM trace file and copy it somewhere you can save it. You can then use the Q.931 Translator tool to analyze the PRI messaging. It's located on the CallManager server at C:\Program Files\Cisco\bin\Q931Translator.exe

If you can't figure out what the problem is with that, then find the SETUP message using the translator and post it up here so we can see what the CallManager is sending.

vidir
Level 1
Level 1

We have the same problem. CCM 3.0(9), AS5300 Gatway with PRI connection to the PSTN. The Gateway is configured as H.323 gateway and the presentation bit is set to "allowed". The PSTN people tell us that the parameter they get from us and tells them wether the presentation is allowed, restricted og prohibited is empty. It would be great if someone has answear to this :-)

Run debug isdn q931 on the AS5300 gateway when you make an outbound call, and please feel free to post it here so we can see what the router is actually sending to the PSTN switch.

Thanks I will be back in my office tomorrow and post it right away.

We are running IOS Version 12.1(5)T4 on our AS5300

GW2#sh deb

ISDN:

ISDN events debugging is on

ISDN Q921 packets debugging is on

ISDN Q931 packets debugging is on

ISDN events debug DSLs. (On/Off/No DSL:1/0/-)

DSL 0 --> 7

1 1 - - - - - -

ISDN Q921 packets debug DSLs. (On/Off/No DSL:1/0/-)

DSL 0 --> 7

1 1 - - - - - -

ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)

DSL 0 --> 7

1 1 - - - - - -

GW2#

GW2#sh log

Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns)

Console logging: disabled

Monitor logging: level debugging, 0 messages logged

Buffer logging: level debugging, 631556 messages logged

Logging Exception size (8192 bytes)

Trap logging: level informational, 88709 message lines logged

Logging to x.x.x.x, 88709 message lines logged

Logging to x.x.x.x, 88709 message lines logged

Log Buffer (500000 bytes):

May 25 09:43:06.771: ISDN Se1:15: Outgoing call id = 0x86C5, dsl 1

May 25 09:43:06.771: ISDN Se1:15: process_pri_call(): call id 0x86C5, number 5951225, speed -1, call

type VOICE

May 25 09:43:06.771: building outgoing channel id for call nfas_int is 0 len is 0

May 25 09:43:06.775: ISDN Se1:15: TX -> INFOc sapi = 0 tei = 0 ns = 2 nr = 90 i = 0x0802043305A

104038090A31803A9839F6C08803535363132323370088035393531323235

May 25 09:43:06.775: SETUP pd = 8 callref = 0x0433

May 25 09:43:06.775: Sending Complete

May 25 09:43:06.775: Bearer Capability i = 0x8090A3

May 25 09:43:06.775: Channel ID i = 0xA9839F

May 25 09:43:06.775: Calling Party Number i = 0x80, '5561223', Plan:Unknown, Type:Unknown

May 25 09:43:06.775: Called Party Number i = 0x80, '5951225', Plan:Unknown, Type:Unknown

May 25 09:43:06.791: ISDN Se1:15: RX <- RRr sapi = 0 tei = 0 nr = 3

May 25 09:43:06.935: ISDN Se1:15: RX <- INFOc sapi = 0 tei = 0 ns = 90 nr = 3 i = 0x08028433021

803A9839F

May 25 09:43:06.935: CALL_PROC pd = 8 callref = 0x8433

May 25 09:43:06.935: Channel ID i = 0xA9839F

May 25 09:43:06.935: ISDN Se1:15: TX -> RRr sapi = 0 tei = 0 nr = 91

May 25 09:43:06.939: ISDN Se1:15: LIF_EVENT: ces/callid 1/0x86C5 CALL_PROCEEDING

May 25 09:43:06.939: ISDN Se1:15: PRI Event: 0, bchan = 30, call type = VOICE

May 25 09:43:06.939: (Se1:15) TX call proc to appl thru CDAPI,call_id (0x86C5)

May 25 09:43:07.283: ISDN Se1:15: RX <- INFOc sapi = 0 tei = 0 ns = 91 nr = 3 i = 0x08028433011

E028288

May 25 09:43:07.287: ALERTING pd = 8 callref = 0x8433

May 25 09:43:07.287: Progress Ind i = 0x8288 - In-band info or appropriate now available

May 25 09:43:07.287: ISDN Se1:15: TX -> RRr sapi = 0 tei = 0 nr = 92

May 25 09:43:07.287: ISDN Se1:15: LIF_EVENT: ces/callid 1/0x86C5 CALL_PROGRESS

May 25 09:43:07.287: ISDN Se1:15: event CALL_PROGRESS dsl 1

May 25 09:43:10.739: ISDN Se1:15: process_disconnect(): call id 0x86C5, call type is VOICE, b_idb 0x

6248256C, ces 1, cause Normal call clearing(0x10)

May 25 09:43:10.743: ISDN Se1:15: TX -> INFOc sapi = 0 tei = 0 ns = 3 nr = 92 i = 0x08020433450

8028090

May 25 09:43:10.743: DISCONNECT pd = 8 callref = 0x0433

May 25 09:43:10.743: Cause i = 0x8090 - Normal call clearing

May 25 09:43:10.751: ISDN Se1:15: RX <- RRr sapi = 0 tei = 0 nr = 4

May 25 09:43:10.883: ISDN Se0:15: RX <- RRp sapi = 0 tei = 0 nr = 127

May 25 09:43:10.887: ISDN Se0:15: TX -> RRf sapi = 0 tei = 0 nr = 28

May 25 09:43:11.035: ISDN Se1:15: RX <- INFOc sapi = 0 tei = 0 ns = 92 nr = 4 i = 0x080284334D

May 25 09:43:11.035: RELEASE pd = 8 callref = 0x8433

May 25 09:43:11.035: ISDN Se1:15: TX -> RRr sapi = 0 tei = 0 nr = 93

May 25 09:43:11.035: ISDN Se1:15: CCPRI_ReleaseCall(): bchan 31, call id 0x86C5, call type VOICE

May 25 09:43:11.035: CC_CHAN_ReleaseChanpri for DSL 1 B-chan 31

May 25 09:43:11.035: CCPRI_ReleaseChan released b_dsl 1 B_Chan 31

May 25 09:43:11.039: ISDN Se1:15: LIF_EVENT: ces/callid 1/0x86C5 CALL_CLEARED

May 25 09:43:11.039: ISDN Se1:15: received CALL_CLEARED call_id 0x86C5

May 25 09:43:11.039: ISDN Se1:15: TX -> INFOc sapi = 0 tei = 0 ns = 4 nr = 93 i = 0x080204335A

May 25 09:43:11.039: RELEASE_COMP pd = 8 callref = 0x0433

May 25 09:43:11.047: ISDN Se1:15: RX <- RRr sapi = 0 tei = 0 nr = 5

GW2#

When the router placed the call to the ISDN switch, the calling number was sent like this:

Calling Party Number i = 0x80, '5561223', Plan:Unknown, Type:Unknown

It is certainly not being blocked. Perhaps because the numbering type is being set as unknown. You could try using a translation-rule, something like this:

translation-rule 5

Rule 1 ^556 556 any national

Then in the pots dial-peer that points to the PSTN, apply the translation-rule to the calling number. Example:

dial-peer 9 pots

destination-pattern 9

direct-inward-dial

port 0:D

translate-outgoing calling 5

Now I don't know that the calling number type is what is causing the problem, but I have certainly seen it before. Many times it depends on the ISDN switch that you are talking to that determines which things to look for.

Nortel made a patch for our PSTN provider because of the empty 'Presentation bit' parameter. After they installed it I had to use the translation rule that you shared with us.

Now everthing is working great.

Thank you so much :-)

No problem. :-)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: