|
Posted by on January 25, 2006, 11:37 pm
If you were Registered and logged in, you could reply and use other advanced thread options
..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.
|
  | |
Posted by Eugene on January 29, 2006, 10:26 pm
If you were Registered and logged in, you could reply and use other advanced thread options
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
|
| Similar Threads | Posted | | Strange Problem w/KX-TA624 Hybrid Phone System | June 8, 2005, 4:52 pm |
| Strange Things Are Happening | December 8, 2006, 3:17 pm |
| E1 IMA seriously problem | May 9, 2006, 10:42 am |
| Problem. | December 21, 2006, 8:07 am |
| Another odd SX2000 Problem | July 11, 2005, 2:00 am |
| Problem With TD1232 | January 17, 2006, 5:48 pm |
| no carrier problem | September 14, 2006, 3:51 pm |
| voicemail integration problem | June 26, 2005, 7:12 pm |
| problem in setting linename in tsp | June 28, 2006, 6:24 am |
| MITEL SX50 PROBLEM | July 16, 2006, 7:00 am |
|
|