Please Help - very strange ISDN problem - Cabling-Design.com Forums

..To me, at least, it is indeed very strange. Please read on - any help

much appreciated.

I am working on adjusting our VRU server code for migration from T1 RBS

to PRI ISDN signaling.

----- DS1 Vendor: Qwest (5ess) OS: UnixWare 7. T1 board: Dialogic D/240SC-T1 API: GlobalCall Symptom: *something* happens to the DS1 circuit, and no more calls can be made.

-----

There is one board on bi-directional DS1 on our DEV environment.

I have got it to the point where the VRU makes calls and interacts with

the database just fine, however after a number of outbound calls (I have not yet established a pattern, but probably more than 23...), somehow the DS1 circuit gets screwed up, and I am unable to make anymore calls. The circuit itself looks fine from my side (using ISDIAG

everything looks good - D channel up, etc.). The vendor, Qwest, also says everything looks fine from their end, although after bouncing the circuit, I am able to make calls for some time until the next time this

happens.

As far as the server code/voice API, After a do a gc_MakeCall, it goes trhough GCEV_PROGRESSING then I get a CCLIBSPECIFIC GCEV_DISCONNECTED event. I am really baffled.

Any idea on what could potentially be the problem? Is it even possible that my software can somehow destabilize the DS1 circuit? Any troubleshooting tips?

I have not yet tried tracing the D-channel activity, although I don't see how that would help, considering the calls initiate, terminate, and

disconnect (and voice and T1 resources get freed up), and the circuit itself somehow gets confused while seemingly reamining operational as far as both I and the vendor can tell. Bouncing the circuit, however, works every time in getting a temporary resolution to the issue.

well, I got some more info.... it looks like this only happens when 64 consecutive calls are made to invalid telephone numbers (i use

1111111111 for testing purposes) - whenever I do a gc_MakeCall to these numbers, i get a CCLIBSPECIFIC disconnect event. This does not happen if i call a valid number and do not receive the CCLIBSPECIFIC disconnect in-between calls to invalid numbers. Strange... so I seems like some kinda bug associated with the CCLIBSPECIFIC event accumulates, causing the D-channel to stop functioning properly.

When the circuit crashes, I can fix it by re-starting the Dialogic board. The only thing the vendor can tell me is that when the circuit is *crashed*, it looks as if all the channels are idle (including the D-channel), however if the try to bounce any of the B channels, they get a 'remote busy'. The only suggestion they have is to try switching from 5ess protocol to DMS100, for no specific reason they can explain... more of a 'well, let's try that instead' type of move..., with which I am not compfortable, since AT&T 5ESS is a standard protocol, supported by the vendor, tmy hardware, and the API, so it should work.

Any ideas? Suggestions? Tips? Maybe it's something that can be configured on the vendor's switch? I have been able to duplicate the issue with the outbound demo application included with GlobalCall API, so I know it's not my server that's causing the issue.

Thanks, Eugene kononovich