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!

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

CS1000 to Cisco Unity

Status
Not open for further replies.

motox2

Programmer
Jun 21, 2007
426
0
0
GY
Does anyone have any DCH setup notes on interconnecting a Cisco Unity (CUC 10.5.2.18900) to a CS1000? Specifically what may be causing the DTA0103 81 7 error message im getting. My system works ok but as i mentioned there is a clock issue throwing those DTA0103 81 7 messages and i can't seem to correct it. The system itself is working fine. The only issue is that when someone calls in on the AA and they press 1 to route to the operator, as soon as the operator picks up the call, the PBX throws the DTA0103 81 7 message every time. Any insight would be great. Thank you kindly.
 
That's not a clock error

DTA0103 loop Problem in loop or channel message of PRI2.
 
Here is a config that has worked for years

ADAN DCH 13
CTYP MSDL
GRP 1
DNUM 0
PORT 2
DES CISCO
USR PRI
DCHL 44
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC ISGF
PINX_CUST 0
ISDN_MCNT 300
CLID OPT0
CO_TYPE STD
SIDE NET
CNEG 1
RLS ID **
RCAP COLP NDI CCBI CCNI PRI DV3I CTI QMWI
PR_TRIGS DIV 2 3
CNG 2 3
PR_RTN NO
MBGA NO
OVLR YES
DIDD 0
OVLS NO
T310 120
T200 3
T203 10
N200 3
N201 260
K 7

DES CISCO
TN 044 01
TYPE TIE
CDEN SD
CUST 0
TRK PRI
PDCA 1
PCML MU
NCOS 6
RTMB 13 1
B-CHANNEL SIGNALING
TGAR 1
AST NO
IAPG 0
CLS UNR DTN CND ECD WTA LPR APN THFD HKD SPCD
P10 VNL
TKID 8013
AACR NO
DATE 15 MAR 2011


TYPE RDB
CUST 00
ROUT 13
DES CISCO
TKTP TIE
M911P NO
ESN NO
CNVT NO
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI
ISDN YES
MODE PRA
IFC ISGF
SBN NO
PNI 00000
NCNA NO
NCRD NO
CHTY BCH
CTYP UKWN
INAC NO
ISAR NO
CPFXS YES
DAPC NO
INTC NO
MBXR NO
DSEL VOD
PTYP PRI
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
SRCH RRB
TRMB YES
STEP
ACOD 8013
TCPP NO
PII NO
AUXP NO
TARG
CLEN 1
BILN NO
OABS
INST
IDC NO
DCNO 0 *
NDNO 0
DEXT NO
ANTK
SIGO STD
ICIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
GRD 896


PAGE 002

SFB 3
NBS 2048
NBL 4096

IENB 5
TFD 0
VSS 0
VGD 6
DRNG NO
CDR NO
VRAT NO
MUS NO
RACD NO
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0
FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
OHQ NO
OHQT 00
CBQ NO
AUTH NO
TDET NO
TTBL 0
ATAN NO
PLEV 2
ALRM NO
ART 0
SGRP 0
ARDN NO
AACR NO
 
Hi KC, thanks for the response. I posted my data below. Not to much difference, but there is slight variations from my programming compared to yours. In other efforts to resolve this situation, as a test i re-routed our main incoming number that hits my Unity CUC to a standard telephone instead of the PC attendant consoles and to my surprise i did not see the DTA0103 message come across the screen as i normally do when the calls are directed to the PC attendants. So I'm wondering if this has something to do with the ATT programming in the CDB. Any more help to resolve this would be awesome. Thanks again!!!!

(using a Dialogic DMG2000 TIMG system)

ADAN DCH 81
CTYP MSDL
MG_CARD 008 1 01
PORT 1
DES CISCO_E1
USR PRI
DCHL 81
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC ISGF
PINX_CUST 0
ISDN_MCNT 300
CLID OPT0
CO_TYPE STD
SIDE NET
CNEG 1
RLS ID **
QCHID YES
RCAP COLP NDI CCNI PRI DV3I CTI QMWI
PR_TRIGS DIV 2 3
CNG 2 3
CTR2 2 3
PR_RTN NO
MBGA NO
OVLR NO
OVLS NO
T310 120
T200 3
T203 10
N200 3
N201 260
K 7

=======================

DES UNITY_TRK
TN 081 01 VIRTUAL
TYPE TIE
CDEN SD
CUST 0
TRK PRI2
PDCA 1
PCML MU
NCOS 5
RTMB 81 1
B-CHANNEL SIGNALING
TGAR 1
AST NO
IAPG 0
CLS UNR DTN CND ECD WTA LPR APN THFD XREP BARD SPCD
P10 VNL
TKID
AACR NO
DATE 26 JAN 2019


=======================

ROUT 81
DES UNITY_RT
TKTP TIE
M911P NO
ESN NO
RPA NO
CNVT NO
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
MODE PRA
IFC ISGF
SBN NO
PNI 00001
NCNA NO
NCRD NO
CTYP CDP
INAC YES
ISAR NO
CPFXS YES
DAPC NO
INTC NO
MBXR NO
MBXOT NPA
MBXT 0
DSEL VCE
PTYP DTT
CNDP UKWN
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
SRCH RRB
TRMB YES
STEP
ACOD 626995
TCPP NO
PII NO
AUXP NO
TARG
CLEN 1
BILN NO
OABS
INST
ANTK
SIGO STD
MFC NO
ICIS YES
OGIS YES
PTUT 0
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096


PAGE 002

RGV 640
GTO 896
GTI 896
SFB 3
NBS 2048
NBL 4096

IENB 5
TFD 0
VSS 0
VGD 6
DTD NO
SCDT NO
2 DT NO
DRNG NO
CDR NO
NATL YES
SSL
CFWR NO
IDOP NO
VRAT NO
MUS NO
PANS YES
EQAR NO
OHQ NO
OHQT 00
CBQ NO
AUTH NO
TTBL 0
ATAN NO
PLEV 2
OPR NO
ALRM NO
ART 0
PECL NO
DCTI 0
TIDY 626995 81
SGRP 0
CCBA NO
ARDN NO
CTBL 0
ACF NO
AACR NO
 
Resolved!!!
The setting that needed to be updated was located within the Dialogic configuration. Login to the Dialogic box and update this setting: Configuration>TDM>T1/E1>General ISDN Settings>QSIG Protocol Specification= ECMA_Only (originally i had this set to ISO). Once this change was made, no more DTA103 errors.
 
Well this was a short lived victory....... I just found out that the MWI lights will not turn on with new messages as long as the Dialogic QSIG Protocol specification is set to ECMA_only. Once i go back to the ISO default setting, the MWI's function as normal. AAAHHHHH!!!!! This is mind numbing!! any thoughts how to resolve this DTA103 messages?
 
What voice Mail System? If Call Pilot you may need the NMS Option, Network Messgage Service.
 
read the first post, it explain it all. I'm using a Cisco Unity system connected through a Dialogic to a 7.65 CS1000 system.
 
I would make sure the patches on your CS1000 are up to date. There is a patch for DTA103 errors for that release it is not your exact problem but I have seen several instances of patches resolving issues of this nature.
 
sorry for the late response on this, but i actually am running SP10 deplist for 7.65 release, so im up to date with the latest patches needless to say. Still haven't gained any ground on this issue but i did find out that when the DTA103 occurs, it has been tested and confirmed a direct result of the Unity AA trying to transfer a call to a 2250 console phone. Any other transfer calls from within the Unity AA transferring to anything other than a 2250 work just fine, no problems. Compounding this DTA103 issue is that after enough of these errors, the channels lock up on the PRI link between the dialogic and the UDT card on the CS1000. So for the time being the problem has been isolated down to transferring calls from the Unity AA to a CS1000 2250 console phone. Looking into a 8 port dialogic box and getting away from the PRI version of it unless a solution can be found.
 
Everything I have found related to this error indicates it needs a Patch. Very possibly Patch MPLR32726. See below. I think your call to the 2250 Console is coincidental. I would get this patch installed for 7.65

CS1000 7.6 sw: DTA103 messages causes DCH to drop when using PRIGateway.
Rate Content Rate this Page

Doc ID: SOLN229000
Version: 3.0
Status: Published
Published date: 21 May 2013
Updated: 02 Dec 2014
Author:
Keith Davis

Details

DCH are going down a couple of times per day
Cisco Switch and Avaya Switch is a EuroIsdn connection to the PSTN,
Feature ECTO-Enhanced Call Transfer enabled on the Cisco Switch and the PSTN,
Please note this issue didn't happen on the NTBK50AA Pri2 Card configured as EuroIsdn.
Problem Clarification

On CS1000, Link to CO is Euroisdn using PRI Gateway hardware.

Incoming Euroisdn call from CO to Set A (Cisco Extension)

Set A answers call and activates ECTO feature (some kind of transfer) back out to CO, with digits dialled that send it to Set B. This can be a blind transfer or consultive transfer
Once Set B(CS1K Extension) answers , then DTA103 is printed, and the DCH drops).
Cause

Software Bug,
D-Channels are going down after DTA103, after receiving CC_FAC_IND message from the Central Office.
Solution

Install Fix Patch MPLR32726
 
Hi KC, i read about that particular patch once before. The patch you referenced was replaced by MPLR33805_1.cpm in SP10 as illustrated on page 27 in the document from the below Avaya link. Since i already have MPLR33805 loaded, if i try to upload MPLR32726 into the system, will it deactivate the newer patch MPLR33805 or in this case would it matter? I suppose it couldn't hurt in any case.

 
UPDATE**
i out'd the newer patch MPLR33805_1.cpm and installed the older patch MPLR32726_1.cpm as a test and same results. I restored the original new patch back in service.
 
Ok so here's the resolution to this infernal problem. After extensive testing, corruption was found on CORE1. As soon as i SCPU over to CORE0, Viola!! no more problems. So now I'm going to reload CORE1 and prey it all works out. I wish i would have found an actual issue i could have reported on, but i will settle for this kind of victory any day!!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top