rhack

Have you monitored the inbound messaging to see if the cpn is in the setup messages? Are you using NTNAPRI protocol? Also if you can get a copy of the DCH config from the Opt 11 that may help.

EricP

Here is how I set up our system to send caller ID to a CCM. We use private caller ID internally so we had to use the NI1 to be able to send it between the two, this is the only protocol that will pass it. I dont know if you are set up that way or not. Below are my translations

>clliref search VOIP_PILOT_1
CLLI "VOIP_PILOT_1" occurs in the following tuples:
Table Key: Sub Tuple
-------- -------> --------------------------------------------------------
CLLI VOIP_PILOT_1 187 24 TEST_PRI_TRUNK_GRP
TRKGRP VOIP_PILOT_1 IBNT2 0 PRAC NCRT PNHSM 0 ASEQ 15
9523342222 ANSDISC 0 Y N N N N N Y 0 15 N 0 0 0 0 N
N N N N N N N N NATL (LTID ISDN 27) $
CLLIMTCE VOIP_PILOT_1 TESTPR 5 10 15 NSS 0 0 N N (23)
IBNRTE 1003 (ISA N N N VOIP_PILOT_1 N PVT 0 PVT 0)
(ISA N N N VOIP_PILOT_2 N PVT 0 PVT 0)
(T OFRT 14) $ $
TRKSGRP VOIP_PILOT_1 0 DS1SIG ISDN 15 15 87Q931 2 N STAND
NETWORK PT_PT USER N UNEQ 10 N 5ESSPARM LTC 5 2 24
64K HDLC $ $
TRKMEM VOIP_PILOT_1 1 0 LTC 5 2 1
TRKMEM VOIP_PILOT_1 2 0 LTC 5 2 2
TRKMEM VOIP_PILOT_1 3 0 LTC 5 2 3
TRKMEM VOIP_PILOT_1 4 0 LTC 5 2 4
TRKMEM VOIP_PILOT_1 5 0 LTC 5 2 5
TRKMEM VOIP_PILOT_1 6 0 LTC 5 2 6
TRKMEM VOIP_PILOT_1 7 0 LTC 5 2 7
TRKMEM VOIP_PILOT_1 8 0 LTC 5 2 8
TRKMEM VOIP_PILOT_1 9 0 LTC 5 2 9
TRKMEM VOIP_PILOT_1 10 0 LTC 5 2 10
TRKMEM VOIP_PILOT_1 11 0 LTC 5 2 11
TRKMEM VOIP_PILOT_1 12 0 LTC 5 2 12
TRKMEM VOIP_PILOT_1 13 0 LTC 5 2 13
TRKMEM VOIP_PILOT_1 14 0 LTC 5 2 14
TRKMEM VOIP_PILOT_1 15 0 LTC 5 2 15
TRKMEM VOIP_PILOT_1 16 0 LTC 5 2 16
TRKMEM VOIP_PILOT_1 17 0 LTC 5 2 17
TRKMEM VOIP_PILOT_1 18 0 LTC 5 2 18
TRKMEM VOIP_PILOT_1 19 0 LTC 5 2 19
TRKMEM VOIP_PILOT_1 20 0 LTC 5 2 20
TRKMEM VOIP_PILOT_1 21 0 LTC 5 2 21
TRKMEM VOIP_PILOT_1 22 0 LTC 5 2 22
TRKMEM VOIP_PILOT_1 23 0 LTC 5 2 23
TRKNAME 187 VOIP_PILOT_1
LTMAP ISDN 27 CLLI VOIP_PILOT_1 (TEI 0) $
=====================
Total of 30
TABLE: LTDEF
ISDN 27 B PRA 23 23 0 0 NTNAPRI V1 NIL (NOPMD ) $
TABLE: LTCALLS
ISDN 27 PVT RTEREF IBNRTE 998 $
ISDN 27 PUB RTEREF IBNRTE 998 $
TABLE: LTDATA
ISDN 27 SERV SERV N Y SCREENED ALWAYS $

Table custnetwork
PNHSM PRIVATE 1 $ (CLID OFFNET) (ECM ) (TCAPNM LOCAL) (RNID OFFNET) $

Table custstn
PNHSM NAMEDISP NAMEDISP

Table isdnparm
5ESSPARM SETUP BOTH MAP (DIE MAP) $
5ESSPARM NOTIFY BOTH MAP (DIE MAP) $

Table netnames
PNHSM 4 5 (NMDSP SETUP) (FACREJ ) $

mountain!!

From a CLID delivery perspective, there is no difference. Contact the TELCO to insure the DMS 250 side has the following option in table CALLATTR for your trunk: ANIDELV CPNPREF.

Since you are on the 250 side of the DMS, I assume the only way to terminate on the trunk is via an 8XX number. Thus, a "regular" directory number can not be dialed and terminate on the trunk. Because people are dialing an 8XX number and the terminating party is paying for the call, the originator gives up all rights to privacy. Per FCC rules, even if the originator has their call blocked, the terminating party still has a right to see it. However, the LEC can not deliver the call if the call is blocked (restricted). The carrier who handles your 8XX number can remove the blocking indicator to allow the LEC to deliver the call. Since you are on the 250 side of the switch the 8XX carrier and the LEC deliverying the call are probably the same company. The 8XX carrier may balk when you suggest they remove the blocking, but FCC rules gives them the authority to do it. If they refuse to remove the blocking indicator....get another 8XX carrier. There are times when the local LEC does not receive and CLID or billing number and can not delivery a calling number. Not much can be done in this scenario.