Making PRI changes

[zigmo36]

Good afternoon, Folks!

I have a Nortel CS1000M, My software version is 3621, and the release is 5, issue 50 J +.

How would I change (and then view the changes of course)the PRI setting to “National ISDN” in the “Nature of Number” fields for our two T-1 circuits?

Thanks very much for any perusal. Happy Thanksgiving!

zigmo36

 

[KCFLHRC]

I'm assuming you want NI2, you change than at the "IFC" prompt. However you will have to change it in the route also. It is probably better to out the trunks, out the route, out the d-channel and build it back as NI2. It may not allow you t make the changes since the interface type is referenced in the d-channel config as well as the route. Is it custom now? Like 5ESS, D100 or something along those lines?

 

[zigmo36]

I show IFC=NI2 already under the ADAN DCH, and the RDB. So that's already there. Do you know where the "nature of number" settings reside?

Thanks, zigmo36

 

[KCFLHRC]

Never heard of "nature of number" setting. Unless you are talking about call type. If that is the case you can send the calls to a DMI table and change the call type if necessary. Is there something in particular that doesn't work?

 

[zigmo36]

The problem we're having is that local outgoing calls (primarily to wireless phones) show an extra erroneous area code in caller ID on the receiver's phone readout. Whereas long distance outgoing calls show only a generic number, even though we have 1600 DID numbers. This second thing may be a separate situation, so fixing the first thing is probably priority.

Anyway, our AT&T guy seems to think the problem is with AT&T wireless and how they receive calls, and he suggested I change the "nature of number" setting in the PRI settings to "national ISDN", and that will fix my problems. I asked him how to do that, and he suggested I contact our vendor. AT&T is our vendor. :+)

Thanks so much for looking at this, KCFLHRC, happy Thanksgiving to you and yours!

zigmo36

 

[KCFLHRC]

This appears to be more of a caller ID issue than the actual interface type.

 

[mckinneyj]

I would turn on d channel messaging in ld 96 and see what you are sending out. Sounds like a telco issue

 

[zigmo36]

Okie dokie, I turned on d channel messaging, thanks mckinneyj. Now how do I look at the history file that info is collected to?

zigmo36

 

[KCFLHRC]

The d-channel messaging is live per call. In LD 96 type ENL MON TTY

 

[Splic3d]

You my need to turn on MON TTY (LD 96) That should be printing it to the terminal, use fie capture if you need to.

http://www.i3techgroup.com

If its not working, get a bigger hammer!

Avaya/Nortel/NEC/Asterisk/Access Control/CCTV/DSX/Acti/UCx

 

[Splic3d]

Sorry - ENL MON TTY

http://www.i3techgroup.com

If its not working, get a bigger hammer!

Avaya/Nortel/NEC/Asterisk/Access Control/CCTV/DSX/Acti/UCx

 

[zigmo36]

Here's what I got. I called my cell phone about the time of this gobbledygook:


DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000EEE9 CH 12 3 TOD 11:43:50 CK ED81CBE2
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000EE69 CH 12 2 TOD 11:43:50 CK ED81CC1F
CONNECT #:5000 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000EEE9 CH 12 3 TOD 11:43:56 CK ED81F798
PROGRESS: TERMINATING END IS NOT ISDN

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 0000EE69 CH 12 2 TOD 11:44:00 CK ED82140D

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 0000EF69 CH 12 2 TOD 11:44:22 CK ED82C6AC

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000EF69 CH 12 2 TOD 11:44:22 CK ED82C6AC
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_DISC_REQ REF 0000EEE9 CH 12 3 TOD 11:44:24 CK ED82D45E
CAUSE: #16 - NORMAL CALL CLEARING

DCH 10 UIPE_OMSG CC_RELEASE_RESP REF 0000EEE9 CH 12 3 TOD 11:44:24 CK ED82D586


DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000EF69 CH 12 2 TOD 11:44:30 CK ED82FF50
PROGRESS: TERMINATING END IS NOT ISDN

DCH 10 UIPE_OMSG CC_DISC_REQ REF 0000EDE9 CH 12 1 TOD 11:44:38 CK ED834115
CAUSE: #16 - NORMAL CALL CLEARING

DCH 10 UIPE_OMSG CC_RELEASE_RESP REF 0000EDE9 CH 12 1 TOD 11:44:38 CK ED83424A


DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 0000EFE9 CH 12 1 TOD 11:44:44 CK ED83759F

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000EFE9 CH 12 1 TOD 11:44:44 CK ED8375A0
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 0000F069 CH 12 3 TOD 11:44:48 CK ED838D5E

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000F069 CH 12 3 TOD 11:44:48 CK ED838D5F
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000F069 CH 12 3 TOD 11:44:52 CK ED83A685
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:4381 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 0000F069 CH 12 3 TOD 11:44:58 CK ED83D8AA

TIM532 11:45 26/11/2013 CPU 0

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 0000ECE9 CH 12 4 TOD 11:45:00 CK ED83EB2D

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000EFE9 CH 12 1 TOD 11:45:06 CK ED841536
CONNECT #:5000 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_DISC_REQ REF 0000EF69 CH 12 2 TOD 11:45:06 CK ED8415F9
CAUSE: #16 - NORMAL CALL CLEARING

DCH 10 UIPE_OMSG CC_RELEASE_RESP REF 0000EF69 CH 12 2 TOD 11:45:06 CK ED841704


DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 0000F0E9 CH 12 2 TOD 11:45:08 CK ED842754

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000F0E9 CH 12 2 TOD 11:45:08 CK ED842754
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000F0E9 CH 12 2 TOD 11:45:10 CK ED8440EA
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:4381 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 0000EFE9 CH 12 1 TOD 11:45:12 CK ED84475D

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 0000F169 CH 12 1 TOD 11:45:16 CK ED846266

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000F169 CH 12 1 TOD 11:45:16 CK ED846270
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000F169 CH 12 1 TOD 11:45:16 CK ED8463EB
CONNECT #:5000 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 0000F1E9 CH 12 3 TOD 11:45:32 CK ED84E4BB

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000F1E9 CH 12 3 TOD 11:45:32 CK ED84E4BC
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 0000F169 CH 12 1 TOD 11:45:34 CK ED84F9F1

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000F1E9 CH 12 3 TOD 11:45:40 CK ED852311
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:3068 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 0000F269 CH 12 1 TOD 11:45:44 CK ED853C39

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000F269 CH 12 1 TOD 11:45:44 CK ED853C39
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 0000F2E9 CH 12 4 TOD 11:45:46 CK ED854CCD

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 0000F2E9 CH 12 4 TOD 11:45:46 CK ED854CD9
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000F2E9 CH 12 4 TOD 11:45:46 CK ED854F94

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 0000F269 CH 12 1 TOD 11:45:48 CK ED855EB5
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:4381 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 0000F2E9 CH 12 4 TOD 11:45:50 CK ED857684

DCH 10 UIPE_OMSG CC_DISC_REQ REF 0000DFE9 CH 12 6 TOD 11:45:54 CK ED8593A3
CAUSE: #16 - NORMAL CALL CLEARING

DCH 10 UIPE_OMSG CC_RELEASE_RESP REF 0000DFE9 CH 12 6 TOD 11:45:54 CK ED8594CD

 

[KCFLHRC]

I don't see anything there that is sending out a 10 digit # , that is more than likely a calling line id table entry issue

 

[zigmo36]

So the caller-ID info is coming from somewhere other than directly from the PBX, like some sort of numbering table or something (which of course is part of the PBX), KCFLHRC?

zigmo36

 

[Splic3d]

This looks as if they are incoming calls on the first PRI, the outgoing calls will most likely go out the 2nd PRI. Each PRI probably has its own D channel. ENL MSGI, ENL MSGO on the second D channel and you will most likely see the outgoing calls.

http://www.i3techgroup.com

If its not working, get a bigger hammer!

Avaya/Nortel/NEC/Asterisk/Access Control/CCTV/DSX/Acti/UCx

 

[KCFLHRC]

The CLID tables are built in LD 15. Then assigned to the phone when you build the key.

 

[zigmo36]

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 00009BEB CH 12 1 TOD 14:17:01 CK EE9A5D25
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:4381 NUM PLAN: UNKNOWN TON: UNKNOWN
**
DCH000
.enl msgo 11
OUTPUT TARGETS: TTY
.
DCH 10 UIPE_OMSG CC_SETUP_RESP REF 00009C6B CH 12 2 TOD 14:17:19 CK EE9AE341
CONNECT #:5000 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 00009C6B CH 12 2 TOD 14:17:23 CK EE9B110D

DCH 10 UIPE_OMSG CC_DISC_REQ REF 0000966B CH 12 7 TOD 14:17:27 CK EE9B274A
CAUSE: #16 - NORMAL CALL CLEARING

DCH 10 UIPE_OMSG CC_RELEASE_RESP REF 0000966B CH 12 7 TOD 14:17:27 CK EE9B2886


DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 00009CEB CH 12 2 TOD 14:17:37 CK EE9B7E02

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 00009CEB CH 12 2 TOD 14:17:37 CK EE9B7E02
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 11 UIPE_OMSG CC_SETUP_REQ REF 00005A8A CH 13 23 TOD 14:17:39 CK EE9B854E
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:4176259799 NUM PLAN: E164 TON: LOCL
CALLED #:4371435 NUM PLAN: E164 TON: LOCL

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 00009D6B CH 12 3 TOD 14:17:41 CK EE9B9024

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 00009D6B CH 12 3 TOD 14:17:41 CK EE9B9030
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 00009D6B CH 12 3 TOD 14:17:41 CK EE9B9330
CONNECT #:5000 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 00009D6B CH 12 3 TOD 14:17:47 CK EE9BC982

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 00009DEB CH 12 3 TOD 14:17:49 CK EE9BDC1C

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 00009DEB CH 12 3 TOD 14:17:49 CK EE9BDC1D
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 00009DEB CH 12 3 TOD 14:17:53 CK EE9BF171
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:4381 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 11 UIPE_OMSG CC_SETUP_REQ REF 00005A8B CH 13 21 TOD 14:17:57 CK EE9C19B9
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:4176594442 NUM PLAN: E164 TON: LOCL
CALLED #:7818244 NUM PLAN: E164 TON: LOCL

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 00009CEB CH 12 2 TOD 14:17:57 CK EE9C1A4F

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 00009E6B CH 12 2 TOD 14:18:05 CK EE9C55B0

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 00009E6B CH 12 2 TOD 14:18:05 CK EE9C55B0
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 00009E6B CH 12 2 TOD 14:18:09 CK EE9C6B59
PROGRESS: TERMINATING END IS NOT ISDN

DCH 10 UIPE_OMSG CC_PROCEED_REQ REF 00009EEB CH 12 4 TOD 14:18:11 CK EE9C7B07

DCH 10 UIPE_OMSG CC_ALERT_REQ REF 00009EEB CH 12 4 TOD 14:18:11 CK EE9C7B07
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 00009EEB CH 12 4 TOD 14:18:13 CK EE9C973C
PROGRESS: TERMINATING END IS NOT ISDN

DTC001


DCH 11 UIPE_OMSG CC_RELEASE_REQ REF 00005A8A CH 13 23 TOD 14:18:15 CK EE9CA389

DCH 11 UIPE_OMSG CC_DISC_REQ REF 00005A87 CH 13 22 TOD 14:18:19 CK EE9CBB88
CAUSE: #16 - NORMAL CALL CLEARING

DCH 11 UIPE_OMSG CC_RELEASE_RESP REF 00005A87 CH 13 22 TOD 14:18:19 CK EE9CBBF
F

 

[Splic3d]

I see 2 local calls going out. DIS MSGO 10 to stop a little of the confusion. 1 showed CLID of 4176259799 the other 4176594442. The 625xxxx are your DID's, I'm guessing 659xxxx is you list CLID. Those are the numbers local calls going out received. Do a LD call and compare. Do a print in LD 21 or LD 22, (never get the right one first) do
REQ - prt
type - clid
enter until it prints the clid tables.

http://www.i3techgroup.com

If its not working, get a bigger hammer!

Avaya/Nortel/NEC/Asterisk/Access Control/CCTV/DSX/Acti/UCx

 

[Splic3d]

Marcus, did you get anywhere with this?

Dan

http://www.i3techgroup.com

If its not working, get a bigger hammer!

Avaya/Nortel/NEC/Asterisk/Access Control/CCTV/DSX/Acti/UCx

 

[zigmo36]

I can't see with the LD 96 monitoring, how anything more than the area code and number is being sent. The erroneous area code must be coming into play somewhere else. What a can of worms!

Thanks for your help, Dan!