Timeout between LISTEN_REQ and LISTEN_CONF?

[Andre]

Hi there,

I have recently taken over development responsibility for a fairly mature
CAPI application, and now I am trying to debug and solve a problem that is
happening at a particular site. Unfortunately I am not local to the site
(other side of the country), nor do I have remote access, and the problem
doesn't happen at my site, so I can't reproduce it in detail, nor do
specific debugging traces.

The symptoms are that, at this site, the application occasionally fails with
one of the following error messages:
- either a "CAPI failed to start listening within timeout period" when it is
trying to move from state L-0.1 to L-1
- or a "CAPI failed to stop listening within timeout period" when it is
trying to move from state L-1.1 to L-0

Looking at the code, I see that the application sends out a LISTEN_REQ with
an InfoMask of "InfoMask_ALL_BUT_EARLYB3CONNECT" (hex 5FF) when it wants to
start listening, or a LISTEN_REQ with an InfoMask of 0 when it wants to stop
listening. So far, so good. The application code then waits for a timeout
period (currently 5 seconds) for the driver to respond with a LISTEN_CONF.
Again, so far, so good -- most of the time.

However, at the problem site, the LISTEN_CONF is often not received within
the timeout period, so everything breaks. The machine is probably
under-powered, so it would make sense for things to happen slowly on the
machine. Again, this is one of those intermittent problems, in that it
sometimes DOES work at that site (perhaps when the machine is not so busy,
although I cannot tell).

My question is two-fold:
- is it a correct and reasonable strategy to implement a timeout when
waiting for the LISTEN_CONF response?
- if so, is 5 seconds a reasonable timeout value?

At this stage, my inclination is just to increase the timeout value to, say,
30 seconds, and get the support technician to try the updated program at the
client site.


Regards,
Andre

[Tobias Erichsen]

Hi Andre,

actually I have yet to see a CAPI-implementation that will not respond to
a LISTEN_REQ pretty immediately. What kind of ISDN-board do you
actually use in this installation?

And just to get an understanding of the load on the machine, how many
channels of calls are we talking about? And what kind of processor is
in use?

Best regards,
Tobias

Post by Andre
Hi there,
I have recently taken over development responsibility for a fairly mature
CAPI application, and now I am trying to debug and solve a problem that is
happening at a particular site. Unfortunately I am not local to the site
(other side of the country), nor do I have remote access, and the problem
doesn't happen at my site, so I can't reproduce it in detail, nor do
specific debugging traces.
The symptoms are that, at this site, the application occasionally fails
- either a "CAPI failed to start listening within timeout period" when it
is trying to move from state L-0.1 to L-1
- or a "CAPI failed to stop listening within timeout period" when it is
trying to move from state L-1.1 to L-0
Looking at the code, I see that the application sends out a LISTEN_REQ
with an InfoMask of "InfoMask_ALL_BUT_EARLYB3CONNECT" (hex 5FF) when it
wants to start listening, or a LISTEN_REQ with an InfoMask of 0 when it
wants to stop listening. So far, so good. The application code then waits
for a timeout period (currently 5 seconds) for the driver to respond with
a LISTEN_CONF. Again, so far, so good -- most of the time.
However, at the problem site, the LISTEN_CONF is often not received within
the timeout period, so everything breaks. The machine is probably
under-powered, so it would make sense for things to happen slowly on the
machine. Again, this is one of those intermittent problems, in that it
sometimes DOES work at that site (perhaps when the machine is not so busy,
although I cannot tell).
- is it a correct and reasonable strategy to implement a timeout when
waiting for the LISTEN_CONF response?
- if so, is 5 seconds a reasonable timeout value?
At this stage, my inclination is just to increase the timeout value to,
say, 30 seconds, and get the support technician to try the updated program
at the client site.
Regards,
Andre

[Andre]

Hi Tobias,

Thanks for your response.

The ISDN boards are 2 x AVM 2-port cards (don't know the model at this
stage, but Manufacturer Version = "49.19" in the log file). However, just to
add to things, there 2 x Dialogic 4-port cards in the same box, and the
Dialogic drivers/services are notorious for sometimes burning 100% of the
CPU (an ongoing problem within their drivers, under certain circumstances).

I don't know any of the specs of the processor, RAM, etc, but our support
technician's opinion was that the machine was underpowered, particularly
relative to what we would spec for a new installation today.

The problem seems to be worse during startup of all the lines, at which
stage all the AVM CAPI lines and all the Dialogic lines would be competing
for resources. It could be that something holds up the servicing of the
Windows message queue for a while, which we use to feed the state of our
state machine.

Thinking about it, it may be that we actually _do_ get the LISTEN_CONF
response to the LISTEN_REQ quite quickly, but that our state machine is slow
to move from the one state to the next (due to CPU load or Windows message
queue problems, or even shortage of RAM leading to one of our modules being
swapped out and then swapped back in). In this case, allowing a longer
timeout for our state machine to change state seems quite reasonable.

Regards,
Andre

Post by Tobias Erichsen
Hi Andre,
actually I have yet to see a CAPI-implementation that will not respond to
a LISTEN_REQ pretty immediately. What kind of ISDN-board do you
actually use in this installation?
And just to get an understanding of the load on the machine, how many
channels of calls are we talking about? And what kind of processor is
in use?
Best regards,
Tobias

Post by Andre
Hi there,
I have recently taken over development responsibility for a fairly mature
CAPI application, and now I am trying to debug and solve a problem that
is happening at a particular site. Unfortunately I am not local to the
site (other side of the country), nor do I have remote access, and the
problem doesn't happen at my site, so I can't reproduce it in detail, nor
do specific debugging traces.
The symptoms are that, at this site, the application occasionally fails
- either a "CAPI failed to start listening within timeout period" when it
is trying to move from state L-0.1 to L-1
- or a "CAPI failed to stop listening within timeout period" when it is
trying to move from state L-1.1 to L-0
Looking at the code, I see that the application sends out a LISTEN_REQ
with an InfoMask of "InfoMask_ALL_BUT_EARLYB3CONNECT" (hex 5FF) when it
wants to start listening, or a LISTEN_REQ with an InfoMask of 0 when it
wants to stop listening. So far, so good. The application code then waits
for a timeout period (currently 5 seconds) for the driver to respond with
a LISTEN_CONF. Again, so far, so good -- most of the time.
However, at the problem site, the LISTEN_CONF is often not received
within the timeout period, so everything breaks. The machine is probably
under-powered, so it would make sense for things to happen slowly on the
machine. Again, this is one of those intermittent problems, in that it
sometimes DOES work at that site (perhaps when the machine is not so
busy, although I cannot tell).
- is it a correct and reasonable strategy to implement a timeout when
waiting for the LISTEN_CONF response?
- if so, is 5 seconds a reasonable timeout value?
At this stage, my inclination is just to increase the timeout value to,
say, 30 seconds, and get the support technician to try the updated
program at the client site.
Regards,
Andre