61c doesn't display calling number 1

[iefbr14]

PRI connection between 61c and Cisco Call Manager. Sending calls out the 61c via DSCs pointed to the CCM RLI.
Calls from 61c to CCM display correct Caller-ID on Cisco phone.
Calls from CCM to 61c do NOT show correct Caller-ID; instead, they show the 4-digit ACOD of the ROUT, plus the channel number (between 1 and 23) the call landed on when coming into the 61c (I.E. 8001-23). How can i get the correct Caller-ID to appear on the Nortel phones?

 

[johnpoole]

are you using qsig? i have the same setup here and it works clean in bith directions

RCAP COLP NDI CCBI CCNI PRI DV3I CTI  QMWI

msg lights dn's names etc all work.. about the only thing that is not extendable is pickup and digs... and i could get a dig to work if i had to


john poole
bellsouth business
columbia,sc

 

[iefbr14]

Using NI2 (both sides). I've had to depend completely on our "service" provider for Nortel configs. But they keep coming back with false statements about things that are "impossible" (several of which were quickly debunked by a guy with 10 hours of lifetime Nortel experience using Google searches).

If I can solve some of these issues with QSIG, that'd be great. CCM side is easy. How much would I have to root out of the 61c (Release 21) in order to make the change?

 

[janeenaj]

run a dch trace for the incomming portion...if cisco is sending the info, then you'll be able to see it on the DCH trace

ld 96 enl msgi x - where x is your dch

 

[iefbr14]

Here is what happens:
DCH 10 UIPE_IMSG CC_SETUP_IND REF 00006480 CH 24 23 TOD 11:50:48
CALLED #:7475 NUM PLAN: UNKNOWN

DCH 10 UIPE_IMSG CC_SETUPCOMP_IND REF 00006480 CH 24 23 TOD 11:50:50

DCH 10 UIPE_IMSG CC_RELEASE_IND REF 00006480 CH 24 23 TOD 11:50:54

 

[janeenaj]

The calling number isn't being sent over the DCH

 

[iefbr14]

Thanks for the reply. My VG on the CCM side is TRYING to send it, apparently - here is a "debug isdn q931" on my 2811:

Dec 7 17:48:10.718: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0021
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x0081, '2475'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '7475'
Plan:Unknown, Type:Unknown
Dec 7 17:48:10.774: ISDN Se0/0/0:23 Q931: RX <- STATUS pd = 8 callref = 0x8021

Cause i = 0x81E4 - Invalid information element contents
Call State i = 0x06
Dec 7 17:48:10.814: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8
021
Channel ID i = 0xA98397
Exclusive, Channel 23
Dec 7 17:48:10.818: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x80
21
Dec 7 17:48:11.478: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x
0021
Cause i = 0x8090 - Normal call clearing
Dec 7 17:48:11.510: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x802
1
Dec 7 17:48:11.526: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref =
0x0021

 

[johnpoole]

are you using isgf or esgf?

john poole
bellsouth business
columbia,sc

 

[iefbr14]

It's NI2.

 

[iefbr14]

ADAN DCH 10
CTYP MSDL
DNUM 8
PORT 1
DES CICSOSCO
USR PRI
DCHL 24
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC NI2
CO_TYPE STD
SIDE USR
CNEG 1
RLS ID **
RCAP
T310 30
T200 3
T203 10
N200 3
N201 260
K 7

 

[janeenaj]

you might want to use ISGF for the IFC on the DCH instead of NI2 and set the Cisco to use the same protocol.

 

[iefbr14]

I'm totally up for that, but don't know anything beyond ld 17, chg, adan . . . A complete Nortel novice. I need to be able to undo whatever I do, so as to preserve the functionality we have (if things go south with this change).

 

[janeenaj]

disable your dch,
disable your loop.
out your trunks,
change the IFC on the dch to ISGF
change the IFC on the route to ISGF.
rebuild your trunk

DO NOT DATADUMP.

do whatever is necessary on the cisco to make the protocol ISGF.

make your test calls.

if things doesn't work out, INI the pbx, and you're back to where you were.

 

[janeenaj]

ld 96
map dch - to find which msdl/tmdi service your dch
dis dch x - where x is your dch number
dis msdl or tmdi x - from the map dch above


ld 60
disl x - where x is your loop

ld 14
req: out 23
type: xxx - whatever you have them as DID, TIE...etc
TN: the first TN in the trunk

ld 17
chg dch IFC prompt to ISGF

ld 16
req: chg
type: rdb
cust: 0
route: whatever route you're using, keep pressing enter until you reach IFC, type in ISGF

ld 14
req: new 23
type: whatever trunk type
tn: 1st TN in the group

Change your cisco stuff

ld 96
enl msdl x or tmdi x fdl - to download the new protocol to the dch interface

ld 60
enll x - your loop number
wait a few for the dch to establish

place test call when loop is up

INI if you're unhappy with new config and your're back to square 1

 

[iefbr14]

Thanks for the detailed help. 61c wouldn't take it, tho. It looks like maybe our release doesn't support ISGF - -

>ld 17

CFN000
MEM AVAIL: (U/P): 7089964 USED: 299219 TOT: 7389183
DISK RECS AVAIL: 2736
DCH AVAIL: 60 USED: 4 TOT: 64
AML AVAIL: 15 USED: 1 TOT: 16
REQ chg

TYPE adan

ADAN chg dch 10

CTYP MSDL
DNUM 08
PORT 1
DES CICSOSCO
DES

USR

IFC isgf


SCH0531
IFC ****

 

[janeenaj]

use esgf then

 

[janeenaj]

sorry, I forgot that pbx in the states can't use ISGF unless you get special permission from Nortel or FCC or something like that to load pkg 131 in pbx located in the states. without pkg 131, you can only use esgf or esig

 

[iefbr14]

Just for fun, I had tried esgf when in that spot - it also refused to cooperate.

 

[janeenaj]

do you have package 263 and 305?, without these packages loaded in your switch, you'll not be able to use the QSIG protocol. In which case, you're stuck with NI2 on the M1 side and customer or NI2 on the Cisco as well.

 

[janeenaj]

remove everything you have listed in the rcap except for colp first before you change the ifc