Windows Forum

Ask something
Discussion Locked

RAS will not Answer

0 helpful
7 replies

by paull

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

We are using the EasyIO 8 port Stallion product with software version 5.5, which is installed into a Windows Server NT4 SP6 Intel based machine.

It has been configured to have 8 modems, 4 of which are used for client dialin, while the other 4 areused as fax recievers/senders. The phone lines have been configured on 2 seperate rotaries.

The problem that I am experiencing occures when a client tries to dial into the server.
When three of the modems are in use and another call attempts to come in ,the modem indicates the call, however it is not picked up. The only way I am able to recitfy the problem is by re-booting the server.

I have checked -
RAS has been set to answer all incoming calls.
All cables are connected correctly.
All phone lines work OK - phone company has tested
Microsoft Technet for RAS problems

Anyone have any ideas?

7 replies

by Former member

It's been awhile working with octopus serial cards, but isn't there a configuration console to assign each of the 8 ports a sort of corresponding COM port? I would check that configuration and ensure that the last modem is working properly (That it can indeed answer calls) and that that last port does not have a conflict with any existing ports..

by noname

Another idea..... Check your log file in the winnt directory or the event log. Are you assigning IP addresses with RAS or another DHCP server.. maybe there are not enough IP addresses available and modem do not answer.....

Cheers

by blackbeard

If this happens everytime you get to the fourth line, then I don't have an answer, but if the problem is sporadic, I'd say you probably want to use Task Scheduler (from IE) to nightly run a batch file (say at 4am) that just stops and starts the RAS services. We had a problem where every so often our RAS server wouldn't pick when it got to a certain line. RAS wan't always properly releasing the line from the previous call. REstarting the service nightly solved our problems.

This discussion is closed to new replies.