05-22-2001 09:08 AM - edited 03-12-2019 11:34 AM
Would someone tell me how to enable the outbound Caller ID on CCM ver 3.0(7).
Thanks,
05-22-2001 10:18 AM
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?
05-22-2001 10:27 AM
Cisco DT-24+ Gateway and a PRI to the PSTN.
05-23-2001 10:16 AM
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.
05-23-2001 08:13 AM
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 :-)
05-23-2001 10:17 AM
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.
05-24-2001 10:20 AM
Thanks I will be back in my office tomorrow and post it right away.
05-25-2001 02:52 AM
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#
05-26-2001 02:38 PM
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.
06-14-2001 10:09 AM
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 :-)
06-14-2001 12:08 PM
No problem. :-)
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: