Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Dch Error or Not?

Status
Not open for further replies.
Midnite1971

Midnite1971

Technical User
Mar 27, 2003
57
US
I've turned on d-channel messaging and one of our PRIs keeps having an incoming CC_FAC_IND message.
What does this mean? I understand the alert messages but not the facility messages and our other PRI does not do this.

CS1000
4.5

Thanks

DCH 1 UIPE_IMSG CC_SETUP_IND REF 00003C03 CH 25 4 TOD 9:39:31 CK DAABFE85
CALLED #:6380 NUM PLAN: UNKNOWN TON: UNKNOWN
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:7037869271 NUM PLAN: E164 TON: NATL

DCH 1 UIPE_OMSG CC_PROCEED_REQ REF 0000BC03 CH 25 4 TOD 9:39:31 CK DAABFE88

DCH 1 UIPE_OMSG CC_ALERT_REQ REF 0000BC03 CH 25 4 TOD 9:39:31 CK DAABFE88
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 5 UIPE_IMSG CC_SETUP_CONF REF 00004AE6 CH 13 13 TOD 9:39:31 CK DAAC00A4

DCH 5 UIPE_IMSG CC_SETUP_CONF REF 00004AE3 CH 13 19 TOD 9:39:31 CK DAAC0147
PROGRESS: TERMINATING END IS NOT ISDN

DCH 1 UIPE_IMSG CC_FAC_IND REF 00003C03 CH 25 4 TOD 9:39:31 CK DAAC01D1

DCH 5 UIPE_OMSG CC_SETUP_REQ REF 00004AE8 CH 13 10 TOD 9:39:31 CK DAAC075F
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:18888348106 NUM PLAN: E164 TON: NATL
CALLED #:17037062248 NUM PLAN: E164 TON: NATL

DCH 5 UIPE_IMSG CC_PROCEED_IND REF 00004AE8 CH 13 10 TOD 9:39:31 CK DAAC0976

DCH 5 UIPE_IMSG CC_ALERT_IND REF 00004AE8 CH 13 10 TOD 9:39:33 CK DAAC1085
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 5 UIPE_IMSG CC_SETUP_CONF REF 00004AE8 CH 13 10 TOD 9:39:33 CK DAAC15EA

DCH 1 UIPE_IMSG CC_SETUP_IND REF 00003C83 CH 25 5 TOD 9:39:35 CK DAAC257A
CALLED #:5513 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLING #:8142741510 NUM PLAN: E164 TON: NATL

DCH 1 UIPE_OMSG CC_PROCEED_REQ REF 0000BC83 CH 25 5 TOD 9:39:35 CK DAAC257C

DCH 1 UIPE_OMSG CC_ALERT_REQ REF 0000BC83 CH 25 5 TOD 9:39:35 CK DAAC257D
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 1 UIPE_IMSG CC_FAC_IND REF 00003C83 CH 25 5 TOD 9:39:35 CK DAAC2934

DCH 1 UIPE_OMSG CC_DISC_REQ REF 0000BB03 CH 25 1 TOD 9:39:37 CK DAAC36F8
CAUSE: #16 - NORMAL CALL CLEARING

DCH 1 UIPE_IMSG CC_RELEASE_IND REF 00003B03 CH 25 1 TOD 9:39:37 CK DAAC3775

DCH 1 UIPE_OMSG CC_RELEASE_RESP REF 0000BB03 CH 25 1 TOD 9:39:37 CK DAAC3775


DCH 5 UIPE_OMSG CC_DISC_REQ REF 00004ADF CH 13 20 TOD 9:39:39 CK DAAC3CFF
CAUSE: #16 - NORMAL CALL CLEARING

DCH 5 UIPE_IMSG CC_RELEASE_IND REF 00004ADF CH 13 20 TOD 9:39:39 CK DAAC3D6E

DCH 5 UIPE_OMSG CC_RELEASE_RESP REF 00004ADF CH 13 20 TOD 9:39:39 CK DAAC3D6
E

DCH 5 UIPE_IMSG CC_SETUP_CONF REF 00004AE7 CH 13 12 TOD 9:39:43 CK DAAC5893

DCH 1 UIPE_OMSG CC_SETUP_RESP REF 0000BC83 CH 25 5 TOD 9:39:43 CK DAAC5B60
PROGRESS: TERMINATING END IS NOT ISDN

DCH 1 UIPE_IMSG CC_SETUPCOMP_IND REF 00003C83 CH 25 5 TOD 9:39:43 CK DAAC5BB8


DCH 5 UIPE_OMSG CC_SETUP_REQ REF 00004AE9 CH 13 20 TOD 9:39:45 CK DAAC72C9
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:7037095941 NUM PLAN: E164 TON: NATL
CALLED #:7034761900 NUM PLAN: E164 TON: NATL

DCH 5 UIPE_IMSG CC_PROCEED_IND REF 00004AE9 CH 13 20 TOD 9:39:45 CK DAAC74F9

DCH 5 UIPE_IMSG CC_ALERT_IND REF 00004AE9 CH 13 20 TOD 9:39:49 CK DAAC89D7
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 1 UIPE_OMSG CC_SETUP_RESP REF 0000BC03 CH 25 4 TOD 9:39:51 CK DAACA197
CONNECT #:5959 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 1 UIPE_IMSG CC_SETUPCOMP_IND REF 00003C03 CH 25 4 TOD 9:39:51 CK DAACA20B


DCH 5 UIPE_OMSG CC_SETUP_REQ REF 00004AEA CH 13 8 TOD 9:39:51 CK DAACA212
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:18002919326 NUM PLAN: E164 TON: NATL
CALLED #:18565805877 NUM PLAN: E164 TON: NATL

DCH 5 UIPE_IMSG CC_PROCEED_IND REF 00004AEA CH 13 8 TOD 9:39:51 CK DAACA364

DCH 5 UIPE_IMSG CC_ALERT_IND REF 00004AEA CH 13 8 TOD 9:39:53 CK DAACB1F1
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 5 UIPE_IMSG CC_SETUP_CONF REF 00004AE9 CH 13 20 TOD 9:39:55 CK DAACC3FC
PROGRESS: TERMINATING END IS NOT ISDN

DCH 1 UIPE_IMSG CC_DISC_IND REF 00003B83 CH 25 2 TOD 9:40:09 CK DAAD28D0
CAUSE: #16 - NORMAL CALL CLEARING

DCH 1 UIPE_OMSG CC_RELEASE_REQ REF 0000BB83 CH 25 2 TOD 9:40:09 CK DAAD28D0

DCH 1 UIPE_IMSG CC_RELEASE_CONF REF 00003B83 CH 25 2 TOD 9:40:09 CK DAAD292F


 
Sort by date Sort by votes
this just looks like normal setup and tear down information

john poole
bellsouth business
columbia,sc
 
Upvote 0 Downvote
It does except for those several setup messages...and they happen on every call out of that PRI.

DCH 1 UIPE_IMSG CC_FAC_IND REF 00003C03 CH 25 4 TOD 9:39:31 CK DAAC01D1

DCH 1 UIPE_IMSG CC_FAC_IND REF 00003C83 CH 25 5 TOD 9:39:35 CK DAAC2934

 
Upvote 0 Downvote
No, just like johnpoole says, these are normal messages.
This is just some Facility Messages being sent to your call server after the call setup. These are inbound Facility messages. Could be a name display update, or a whole list of other things.

You could capture these in MON 2 and have someone debig the HEX to see exactly whatit is saying, but there is NO indication of an error in these messages.

--
Fletch

Nortel Emergency Services PLM
 
Upvote 0 Downvote
OK....here's one with hex.
Thanks!!

DCH 1 UIPE_IMSG CC_SETUP_IND REF 00007F83 CH 25 7 TOD 10:45:23 CK DB249E77
PRIM HDR: 2F 00 03 00 5C 00
MSG HDR: 08 02 03 FF 2E 00
BCAP: 01 07 13 00 85 90 00 00 A2
CHID: 09 09 0D 00 A9 00 83 00 01 0CAD#: 03 0A 03 00 80 00 04 00 07 06 07 08
GFFAC: 37 1A 19 00 9F 00 8B 01 00 01 00 A1 0F 02 01 01
06 07 2A 86 48 CE 15 00 04 0PROGI: 1E 04 03 00 82 83
CLG#: 05 10 07 00 21 83 0A 00 02 01 05 06 01 06 0A 06
08 04

DCH 1 UIPE_IMSG CC_FAC_IND REF 00007F83 CH 25 7 TOD 10:45:23 CK DB24A1DD
PRIM HDR: 2F 00 03 00 2A 00
MSG HDR: 08 02 03 FF 23 00
GFFAC: 37 22 19 00 9F 00 8B 01 00 01 00 A1 17 02 01 01
02 01 00 80

DCH 1 UIPE_IMSG CC_SETUPCOMP_IND REF 00007F83 CH 25 7 TOD 10:45:25 CK DB24AEE9
PRIM HDR: 2F 00 03 00 06 00
MSG HDR: 08 02 03 FF 38 00

DCH 1 UIPE_IMSG CC_RELEASE_IND REF 00007F83 CH 25 7 TOD 10:47:01 CK DB27A2BB
PRIM HDR: 2F 00 03 00 06 00
MSG HDR: 08 02 03 FF 2C 00



 
Upvote 0 Downvote
5ESS....set at NI2...here's the Dch programming. On one of the PRIs they had it setup with RCAP- COLP and NDS, I removed NDS and at least the fast busies went away.

ADAN DCH 1
CTYP MSDL
DNUM 14
PORT 3
DES PAETEC
USR PRI
DCHL 25
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC NI2
ISDN_MCNT 300
CLID OPT0
CO_TYPE STD
SIDE USR
CNEG 1
RLS ID **
RCAP COLP
MBGA NO
OVLR NO
OVLS NO
T310 120
T200 3
T203 10
N200 3
N201 260
K 7
BSRV NO

ADAN DCH 5
CTYP MSDL
DNUM 14
PORT 1
DES PAETEC
USR PRI
DCHL 13
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC NI2
ISDN_MCNT 300
CLID OPT0
CO_TYPE STD
SIDE USR
CNEG 1
RLS ID **
RCAP COLP
MBGA NO
OVLR NO
OVLS NO
T310 120
T200 3
T203 10
N200 3
N201 260
K 7
BSRV NO

 
Upvote 0 Downvote
In general facility messages are a real pain to decode. You hadn't mentioned that you were getting fast busy conditions.

Since the FB has cleared, there was obviously some Supplementary Signaling message with CPND being sent with the setup when you had NDS set on the RCAP.

There is a little known fact about DCH messaging that may interest you. The flow looks like this:

[PBX]<----UIPE---->[MSDL CARD]<----Q.931---->[CO]

When you enable DCH monitoring you are actually looking at the UIPE messaging. You need to enable the DEBUG mode on the monitoring to look at the raw Q.931/Q.932 side. If you do this, the Hex is MUCH easier to decode.

DEBUG monitoring mode used to require a password to enable (I think prior to 4.00) but in the newer releases the password option was relaxed and removed.

If you REALLY need to see what those facility messages are, you can capture MON2 in DEBUG mode (documented in the NTPs) and it can be picked apart, but it seems your issue is resolved by removing the NDS in the RCAP.

As always, you should do your captures during a slow period. Release 5.00 and higher allows you to capture to a log file on the PBX and is a bit easier on the CPU cycles. In any case, overloading the messaging output is never good, and if you get a flood of messages, you could have a negative impact on the system. Again, always best to do this during a quiet period until you know for sure what you are working with.

--
Fletch

Nortel Emergency Services PLM
 
Upvote 0 Downvote
Thanks so much for your help.....it's appreciated.

I have turned on dch messaging in and out for both of those PRIs....and we're an Outbound Call Center. Will so many messages being spit out affect the PBX in any way?

Thanks
 
Upvote 0 Downvote
As always, you should do your captures during a slow period. Release 5.00 and higher allows you to capture to a log file on the PBX and is a bit easier on the CPU cycles. In any case, overloading the messaging output is never good, and if you get a flood of messages, you could have a negative impact on the system. Again, always best to do this during a quiet period until you know for sure what you are working with.

--
Fletch

Nortel Emergency Services PLM

Don't forget about the FREE E911 Webinar Oct. 30th!
Register online at
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

lastation4
  • Locked
  • Question
Can't get T1 DCH to establish
Replies
6
Views
656
lastation4
lastation4
telepath
  • Locked
  • Question
Change the SIDE to NET of a DCH 1
Replies
3
Views
484
telepath
telepath
BCU
  • Locked
  • Question
Caller id is not getting displayed
Replies
3
Views
690
gbtac3
gbtac3
John Tel
  • Locked
  • Question
CS1K Signaling Server partition full /dev/hda10 (Not the normal /var issue). Directory not working.
Replies
4
Views
870
John Tel
John Tel
Ozphonebloke
  • Locked
  • Question
Option 11C PSU cct diagram or voltage pinout
Replies
1
Views
473
Ozphonebloke
Ozphonebloke

Part and Inventory Search

Sponsor

Back
Top