Terminating CLID on forwarded call

[zstic78]

I have a strange situation happening I hope someone can help with.

Incoming call to desk phone that is set up to hunt to the user's cell phone

DCH 18 IMSG SETUP REF 000090BC CH 2 1 TOD 11:21:58
PROGRESS: CALL IS NOT END TO END ISDN
CALLING #:313xxxxxxx NUM PLAN: E164/NATIONAL / NPA shows full 10 digit number inbound
CALLED #:6181 NUM PLAN: E164/SUBSCRIBER (NXX)/LOCL

DCH 18 OMSG ALERT REF 000090BC CH 2 1 TOD 11:21:58


Same Call after being forwarded out to the cell phone
DCH 18 OMSG SETUP REF 00000027 CH 18 15 TOD 11:22:12
CALLING #:13xxxxxxx NUM PLAN: E164/NATIONAL / NPA The first digit is missing when presented to the cell phone and displays as 1(3xx)xxx-xx
CALLED #:248xxxxxxx NUM PLAN: E164/NATIONAL / NPA User's Cell phone

DCH 18 IMSG STATUS REF 00000027 CH 18 15 TOD 11:22:12
CAUSE :UNIMPLEMENTED IE
STATE : CALL INIT ST

This is using Route 0 for both in and out bound (DID and Local)
The RLI is 0
FEAT rlb
RLI 0

RLI 0
ELC NO
ENTR 0
LTER NO
ROUT 0
TOD 0 ON 1 ON 2 ON 3 ON
4 ON 5 ON 6 ON 7 ON
VNS NO
CNV NO
EXP NO
FRL 1
DMI 3
CTBL 0
FCI 0
FSNI 0
DORG NO
SBOC NRR
IDBB DBD
IOHQ NO
OHQ NO
CBQ NO

DMI is 3
dgt
DMI 3


DMI 3
DEL 0
ISPN NO
CTYP INTL

LTM Route 0
TYPE TLST
TKTP DID
ROUT 0
DES VZLOCAL
TN 002 01 MBER 1 LOCAL 1
TN 002 02 MBER 2 LOCAL 1
TN 002 03 MBER 3 LOCAL 1
TN 002 04 MBER 4 LOCAL 1
TN 002 05 MBER 5 LOCAL 1
TN 002 06 MBER 6 LOCAL 1
TN 002 07 MBER 7 LOCAL 1
TN 002 08 MBER 8 LOCAL 1
TN 002 09 MBER 9 LOCAL 1
TN 002 10 MBER 10 LOCAL 1
TN 002 11 MBER 11 LOCAL 1
TN 002 12 MBER 12 LOCAL 1
TN 002 13 MBER 13 LOCAL 1
TN 002 14 MBER 14 LOCAL 1
TN 002 15 MBER 15 LOCAL 1
TN 002 16 MBER 16 LOCAL 1
TN 002 17 MBER 17 LOCAL 1
TN 002 18 MBER 18 LOCAL 1
TN 002 19 MBER 19 LOCAL 1
TN 002 20 MBER 20 LOCAL 1
TN 002 21 MBER 21 LOCAL 1
TN 002 22 MBER 22 LOCAL 1
TN 002 23 MBER 23 LOCAL 1
TN 003 01 MBER 25 LOCAL 2
TN 003 02 MBER 26 LOCAL 2
TN 003 03 MBER 27 LOCAL 2
TN 003 04 MBER 28 LOCAL 2
TN 003 05 MBER 29 LOCAL 2
TN 003 06 MBER 30 LOCAL 2
TN 003 07 MBER 31 LOCAL 2
TN 003 08 MBER 32 LOCAL 2
TN 003 09 MBER 33 LOCAL 2
TN 003 10 MBER 34 LOCAL 2
TN 003 11 MBER 35 LOCAL 2
TN 003 12 MBER 36 LOCAL 2
TN 003 13 MBER 37 LOCAL 2
TN 003 14 MBER 38 LOCAL 2
TN 003 15 MBER 39 LOCAL 2
TN 003 16 MBER 40 LOCAL 2
TN 003 17 MBER 41 LOCAL 2
TN 003 18 MBER 42 LOCAL 2
TN 003 19 MBER 43 LOCAL 2
TN 003 20 MBER 44 LOCAL 2
TN 003 21 MBER 45 LOCAL 2
TN 003 22 MBER 46 LOCAL 2
TN 003 23 MBER 47 LOCAL 2
TN 003 24 MBER 48 LOCAL 2
TN 018 01 MBER 49 LOCAL 3
TN 018 02 MBER 50 LOCAL 3
TN 018 03 MBER 51 LOCAL 3
TN 018 04 MBER 52 LOCAL 3
TN 018 05 MBER 53 LOCAL 3
TN 018 06 MBER 54 LOCAL 3
TN 018 07 MBER 55 LOCAL 3
TN 018 08 MBER 56 LOCAL 3
TN 018 09 MBER 57 LOCAL 3
TN 018 10 MBER 58 LOCAL 3
TN 018 11 MBER 59 LOCAL 3
TN 018 12 MBER 60 LOCAL 3
TN 018 13 MBER 61 LOCAL 3
TN 018 14 MBER 62 LOCAL 3
TN 018 15 MBER 63 LOCAL 3
TN 018 16 MBER 64 LOCAL 3
TN 018 17 MBER 65 LOCAL 3
TN 018 18 MBER 66 LOCAL 3
TN 018 19 MBER 67 LOCAL 3
TN 018 20 MBER 68 LOCAL 3
TN 018 21 MBER 69 LOCAL 3
TN 018 22 MBER 70 LOCAL 3
TN 018 23 MBER 71 LOCAL 3



Thanks for taking the time to look, any suggestions

 

[Firebird Scrambler]

I've found this reference for a UK switch that I think might give you a clue. It might be worthwhile changing DMI 3 so that ISPN = YES

DMI 3
DEL 0
ISPN YES
CTYP INTL (This might need changing to NCHG ?)

Problem
CLI not being displayed on outgoing PSTN calls from CS1000E

Answer
The problem was When extension on E switch dials out customer wishes the std number including extension to be displayed. They only want this on certain extensions and are trying to effect this by using the DAPC tables in CLID data in CDB. Then assigning the particular key to the corresponding table. In this case table 1
CLID is outputting 4 digit extension number to some mobiles. To other mobiles it shows 'Private Number' Customer wants to send e.g. 894 8666 - as in his telephone number. Engineer advises CLID is ok if dialled direct from the 'T' switch.
If an extension is provided on the T switch the clid goes out ok but when coming from the E switch does not appear to be inserting the data from thee clid table.

I installed patch mplr23619 on the 1000E
This patch is recommended to be used to build the CLID digits/TON/NPI correctly for
local/national and international public calls tandeming over a private MCDN TDM/IP Peer network to PSTN using SPN dialing plan.
As per the CS 1000E Planning and Engineering NTP, Numbering plan recommendation section,
build the called number at the 1000E and 1000T node. The NTP recommends to set the ISPN
prompt to Y to build the CLID in the NXX format correctly. But this gives limited
options to build the CLID. This patch enhances building the CLID for all three types of
calls (local/National and international ) depending on the CLTP value for the SPN.

Depending upon the CLTP (under SPN prompt in LD 90) setting, the CLID will be built
accordingly.

1)

CLTP = LOCL

CLID = HLCL (Area code) + DN (if DIDN = yes)

= HLCL (Area code) (if DIDN = no).

TON = Subscriber NPI = E.164

2)

CLTP = NATL

CLID = HNTN (National Code) +HLCL (Area code) + DN (if DIDN = yes)

= HNTN (National Code) + HLCL (Area code) (if DIDN = no).

TON = National NPI = E.164

3)

CLTP =INTL

CLID = INTL (International Code) +HNTN (National Code) +HLCL (Area code) + DN (if DIDN =
yes)

= INTL (International Code) +HNTN (National Code) +HLCL (Area code) (if DIDN = no).

TON = Subscriber NPI = E.164

4)

CLTP = NONE

CLID = HLOC (Node) + DN

TON = Private NPI = Private.

Please note :

DMI CTYP (LD 86) will override the SPN CLTP (LD 90). Originating end should use DMI 0
or DMI other than 0 with CTYP nchg
Patch has impact only at the call originating node (1000E) and no impact at the
tandem/gateway node (1000T)
Patch will work only for SL1/IP Peer interfaces
For calls originating at the gateway node to PSTN, it is recommended
to use the DMI CTYP (LD 86) to change the TON/NPI of the called and calling party number.

The full number was now going out to pstn but still no clid. I noticed that the number plan was E164 and the ton was unknown. On a good call from the T switch the ton was NATL. I have made changes on the RDB on the pstn route on the T switch as follows. Created a dummy IDC table ,in this case 2. Changed IDC to yes and made the prompt SDID to yes. This then opens a prompt COTN and against this put NATL. This has changed the TON on the call from unknown to NATL and all now works. I advised field engineer to change all the SPNs CLTP to NATL.



Firebird Scrambler
Nortel Meridian 1 / Succession and BCM / Norstar Programmer in the UK
Advance knowledge on BCM support

http://www.linkedin.com/in/davidbromley

 

[zstic78]

Thanks for the fast reply FirebirdScrambler, I followed your suggestion and changed the ISPN to yes, and CTYP to NCHG, with the same result.
DMI 3


DMI 3
DEL 0
ISPN YES
CTYP NCHG

The strange thing is that a normal outbound call shows up correctly
DCH 18 OMSG SETUP REF 0000002D CH 18 21 TOD 13:00:47
CALLING #:248xxxxxxx NUM PLAN: E164/NATIONAL / NPA
CALLED #:18662793652 NUM PLAN: E164/NATIONAL / NPA

This seems to be happening only on forwards

 

[Firebird Scrambler]

I've found some other info on redirecting CLID's

Problem
Unable to get a phantom DN to send the redirecting DDI extn number back out to the PSTN over Euro-isdn

Answer
Euro-isdn DDI call, routed to a phantom DN was forwarded by means of DCFW, back out over the Euro-isdn PSTN
but was showing the CLI of the original caller, ie 0121 230 8600 & not the customer DDI number.

The CLID values configured against CLID tables in net data of LD 15 does not work for redirected calls. To achive the last redirecting number to be sent to the exchange over a Euro-isdn circuit the OCLI prompt in the net data of LD15 needs to be changed from OCLI = no to OCLI = ext or OCLI = all

These two non default values, represent redirecting of external calls with EXT and the ALL value with allow internally dialled calls, to also be included in the redirecting OCLI enhancement.



Firebird Scrambler
Nortel Meridian 1 / Succession and BCM / Norstar Programmer in the UK
Advance knowledge on BCM support

http://www.linkedin.com/in/davidbromley

 

[zstic78]

Sorry for the delayed response, things have been crazy. Thanks for the reply Firebird Scrambler. I will look into the suggestion.

 

[steve64]

Try changing the "DORG" in the RLB to "YES". you should also change the NCNA and NCRD in the RDB to yes. We had this same issue and making these changes fixed the CLID issue.

 

[zstic78]

While tracking this issue during our SIP testing I found there are other settings in play.
In the route there are two settings that seem to have an affect on this, and I am trying to narrow it down.
TYPE RDB
CUST 00
ROUT 50
DES SIP TRUNK
TKTP TIE
M911P NO
ESN NO
CNVT NO
SAT NO
RCLS EXT
VTRK YES
ZONE 00003
PCID SIP
CRID YES
SBWM NO
NODE 1000
DTRK NO
ISDN YES
MODE ISLD
DCH 50
IFC SL1
PNI 00001
NCNA YES
NCRD NO
FALT NO
CTYP INTL Call type for outgoing direct dialed TIE route (CTYP)

INAC YES
ISAR NO
DAPC NO
MBXR NO
MBXOT INTL
MBXT 0
PTYP ATT
CNDP NATL Calling number dialing plan (CNDP)

Then there is the RLI that has
Route List Block Index -- 26
Initial Set: 0
Number of Alternate Routing Attempts: 5
Set Minimum Facility Restriction Level : 0
Data Entry Index -- 0

Route Number: 50
Expensive Route: N
Facility Restriction Level: 0
Digit Manipulation Index: 26
ISL D-Channel Down Digit Manipulation Index: 0
Free Calling Area Screening Index: 0
Free Special Number Screening Index: 0

Digit Manipulation Block Index -- 26
Number of leading digits to be deleted: 0
Call Type to be used by the manipulated digits : NCHG

 

[Firebird Scrambler]

I think you will need to look in the DAPC table area in LD 15 in order to add in the national and international codes.

The UK examples are shown below.

FTR_DATA
**DAPC**PREFIX TABLE NO: 00 **
UNKN**INTL**NATL**ESPN**LOCL**ELOC**ECDP**
UNKN*
E164* 00 0
PRIV*
E163* 00 0
TELX*
X121*
NATL*

**DAPC**PREFIX TABLE NO: 01 **
UNKN**INTL**NATL**ESPN**LOCL**ELOC**ECDP**
UNKN*
E164* 900 90
PRIV*
E163* 900 90
TELX*
X121*
NATL*

Against your route 50, the DAPC prompt will need to be changed to "YES" and then add in the table entry that you have created.


Firebird Scrambler
Nortel and Avaya Meridian 1 / Succession and BCM / Norstar Programmer in the UK
Very advance high level knowledge on Linux BCM with keycode support

http://www.linkedin.com/in/davidbromley

 

[zstic78]

FirebirdScrambler, thanks again for taking the time to read and reply. We have only one DAPC table. I have seen this while attempting to troubleshoot this, but wasn't sure of the impact. I will do more digging into the NTP to see how the configuration is making me beat my head against the wall. hehe

At a quick glance it looks like this may be a way to ID the type of call?
TYPE FTR_DATA
CUST 00
TBL
**DAPC**PREFIX TABLE NO: 00 **
UNKN**INTL**NATL**ESPN**LOCL**ELOC**ECDP**
UNKN*
E164* 00 0
PRIV*
E163* 00 0
TELX*
X121*
NATL*

I've noticed that the calls that have3 the correct CLID (1248xxxxxxx) are SPN set as INTL but the ones that are not correct (248xxxxxxx) are NPA.
To prove this I changed the 1313 NPA to SPN and it has the correct CLID. I am thinking of making all NPAs a SPN. Do you think thee would be any possible backlash in other areas in doing this?

Special Number -- 1313
Flexible length: 0
Type of call that is defined by the special number: INTL
Route list index: 0

 

[Firebird Scrambler]

Table 0 is there as default and you have the option to add in extra tables. They can be different for each route.


Firebird Scrambler
Nortel and Avaya Meridian 1 / Succession and BCM / Norstar Programmer in the UK
Very advance high level knowledge on Linux BCM with keycode support

http://www.linkedin.com/in/davidbromley