analog boards perfect call analysis question

From: Baji Panchumarti

hello,

I am using analog boards (D/4PCI & D/41D on SR5.1 on redhat Linux 7.3) that get their lines from a phone system (don't have info on it) that is using a PRI.

So the analog lines I receive are simulated analog lines.

My app (outbound) would run fine at times and get stuck at other times on some channels. Repeated test calls to myself *almost* always completed without a hitch.

After trying a dozen different things, h/w & s/w, to fix the issue (changing line sensitivity jumpers, IRQ, pause time after going ON-HOOK, ...), without success, I put an analog phone on each line/channel and listened to them when that line got stuck. In every case I heard a loud rapid busy.

I managed to record the two kinds of busies I receive on these lines in a wav file and I ran it thru two shareware programs on windows (WaveShow by Paul Warme & Spectrum Analyzer Pro by Frank Dunkel), turns out that the dialtone and BUSY1 both use a 438Hz signal (dialtone is a continous signal while BUSY1 has on & off periods), while BUSY2 is composite with most of its amplitude at 2054Hz.

I changed LCL_DIAL, BUSY1 & BUSY2 using dx_chgfreq() & dx_chg_dur() based on what I learned from above, followed by a call to dx_deltones() followed by a call to dx_initcallp().

Haven't had any stuck calls since but the busies are being detected as PVD due to Loop Current Drop.

In my dx_dial() the only two non-default DX_CAP params I set are :

  ca_intflg = DX_PAMDOPTEN;
  ca_pamd_spdval = PAMD_QUICK;

I plan to adjust RNGBK1 & RNGBK2 from the default when I have a chance to listen/record their cadence.

If someone has tips on how I can do a better job at recognizing busies, I am all ears.

thnx,

-baji.

--
To reply: mailto:General.29903@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