Immediate DISCONNECT after gc_MakeCall on DM3

From: Randy Moore

-Hi,

I'm working with Brett McCoy on the oubound calling problem he has mentioned a previous thread and wanted to give some more details of our problem.

First, the short description of the problem is that when we make an outbound call using gc_MakeCall, we are getting a GCDEV_DISCONNECTED event and then a GCDEV_DISCONNECTED event immediately after dialing completes. The reason given for the disconnect is always Remote Termination (0x13). Again, this happens before the call has been answered and usually before the called phone line starts ringing.

And, interestingly, if we ignore the GCDEV_DISCONNECTED event the phone does continue to ring and if someone answers, the listener can hear audio we send with dx_play.

This is true whether we use the SYNC or ASYNC programming model. While most of our testing has been with the SYNC model, I've replicated this using both the gc_basic_call_model demo (slightly modified) and
Gerry Gilmore's very nice gcdiag program from his dial-utils package, and even the Qscript phone utility.

Inbound calls are working perfectly.

Here are some specs for our setup:

2x DM/V960-4T1-PCIU cards
Redhat Linux 7.3 kernel 2.4.20-18.7
LiS Streams Version 2.15.2 2/8/03
Dialogic Release 5.1 FP1 (with all packages installed even though we are only using DM3)
Global Call Protocol package 4.0

Using protocol pdk_us_mf_io

PCDName : ml1_qs_cas.pcd
FCDName : ml1_qs_cas.fcd

File pdk.cfg contains:
board { 1 2 } fcdfile ml1_qs_cas.fcd pcdfile ml1_qs_cas.pcd variant pdk_us_mf_io.cdp

Our T1 trunks are being provided by Global Crossing and are all configure for both inbound and outbound calls.

Our line type and coding on the T1's are ESF & B8ZS. I've heard that this is an unusal setting for T1 trunks for voice and that D4 & AMI is more common, but I don't know if this "unusual" combination could contribute to this problem.

In my ml1_qs_cas.config file for each trunk I have:
SetParm=0x1601,1 ! LineType (dsx1_D4=0, dsx1_ESF=1)
SetParm=0x1602,4 ! SignalingType (CAS=4, CCS=5, Clear=6)
SetParm=0x1603,7 ! Coding (B8ZS=7, AMI=8)
SetParm=0x1604,13 ! ZeroCodeSuppression (Bell=10, GTE=11, DDS=12, None=13)

Here is a snippet from a cheetah.log
22:29:25.626: APPL Libdm3cc dtiB1T2 <:::: gc_GetCallState(0x2, 0xbfffda4c)
22:29:25.626: INFO Dm3Tsc dtiB1T2 <<--- CallState_Disconnected(0x00001000), Reason = 0x13
22:29:25.626: DEBG Call dtiB1T2 <000> Cause = 0xd3
22:29:25.626: DEBG Call dtiB1T2 <000> From state CONNECTED to state DISCONNECTED
22:29:25.626: APPL LineDevice dtiB1T2 <000> SendEvent GCEV_DISCONNECTED (Cause = d3, SigInfoId=65535)
22:29:25.626: DEBG Call dtiB1T2 <000> CallEvent_Disconnected in CONNECTED => DISCONNECTED
22:29:25.626: APPL Libdm3cc dtiB1T2 ::::> gc_GetCallState returns 0

And a bit of the gcdiag tracking log:
LOG1: Placing Call on dtiB1T2 - Num: 3014081200
LOG2: GCEV_ALERTING event on dtiB1T2
LOG2: GCEV_CONNECTED event on dtiB1T2
LOG2: GCEV_DISCONNECTED event on dtiB1T2
LOG1: Dropping Call on dtiB1T2
LOG2: GCEV_DROPPED event on dtiB1T2
LOG2: GCEV_RELEASECALL event on dtiB1T2
LOG3: Closing all GC devices
LOG3: Closing all voice devices

Here are some thoughts & options I'm considering.

Maybe our T1 line type & coding don't work for T1 voice trunks. Thoughts?
        
Maybe there is some protocol error between here & Global Crossing. - I have not found any tools that will let me see to the low level signaling to see if GlobalCrossing is really sending a CAS_REMOTE_DISCONNECT. I've seen several tools for Springware boards, but none that work with DM3. Is there any way to watch at this level? I don't understand why we get the CONNECTED & DISCONNECTED (Remote termination) events before the phone even rings.
        
Our application will be similar to a prepaid calling platform where after someone dials in, they make a selection and an outbound call is placed. We don't want any call analysis in this case, so that we can immediately route the inbound call & outbound call together (hairpin model?). But when testing, I haven't been able to get any call analysis to work ever.
        
Maybe a problem in the pdk_us_mf_io protocl from the 4.0 protocol package. I see in the relase notes for this PTR#30041, but can't find any reference to it in the PTR's on the support site and I'm not sure it is relevant anyway. Might downgrading to 3.0 or even 2.0 help?
        
>From what I've read, we don't have the choice of using anything but the PDK protocols with DM3 boards. Is this correct? I've experimented with using ml1_qs_t1.fcd & the ICAPI protocl. I could get incoming calls to work, but not outgoing (I could never get anything but a Protocl Error on outgoing).
        
I installed packages for all hardware types, rather than just DM3. Might re-install with just the needed packages make a difference?
        
Could downgrading to Dialogic Release 5.1 SP1 (or lower) make a difference?
        
If we were to switch from T1 trunks to ISDN trunks would we be any less likely to have this kind of a problem? My impression is that the out of band call signaling should be a lot harder to mess up.
        
Sorry about the extremely long post, but we've been spinning our wheels on this for a couple of weeks. I'd really appeciate any suggestions you might have on the best approach to take to get this resolved.

Thanks much!

- Randy Moore

To reply: mailto:General.26275@pysdiscussext.py.intel.com
To start a new topic: mailto:General@pysdiscussext.py.intel.com
To login: http://members.support.dialogic.com/wbproxy/wbpx.dll/~general
Received on Tue Nov 04 23:54:47 2003