HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] patton 2977 configuration

ACL wrote:
I noticed that 2977 does not busy out the channel after the caller is disconnected. There are two modems active (ttyG0 and ttyG1). I dial in (ttyG0), hear faxtone and hang up. Then, I dial in again at once. I hear nothing for a few seconds and then the same modem (ttyG0) begins answering again. If 2977 could busy out the channel, ttyG1 should pick up the call.

To the best of my knowledge the Patton 2977 does not have a mechanism to "busy out" a modem/channel from the AT interface.

This causes me trouble because the dnis and callerid is missing in the log for the second call (no NDID and NMBR). If I dial in after the modem is idle, dnis/callerid appears in the log.

Yes, this is very familiar to me. It's been a while since I have stopped using Patton 2977s... and I don't have their config files around any more. I seem to recall there being an AT command to "repeat" the Caller*ID information. Maybe it was AT+VRID. (?) You would put that command into ModemRingResponse and configure ModemRingsBeforeResponse to something like 2. Also, you'd want to use CallIDAnswerLength for that CallIDPattern so that answering is triggered by the Caller*ID information. RingsBeforeAnswer should be set to 0 or to something ridiculously high (like 9).

My telco routes incoming call to the next nonbusy channel. The above situation is very likely to happen. I will get a lot of faxes without dnis/callerid

In my experience getting the modem to repeat Caller*ID was sufficient to not worry about trying to busy-out the channel. If you really do need to busy-out the channel you may want to try using the ATH1 command in ModemResetCmds and then ATH0 in ModemReadyCmds. However, I never tried this on a Patton 2977, I don't think.

BTW, I have been using 2977 in windows for a long time. The same situation happens. However, we could obtain dnis/callerid for every call by issuing at#cid=10 before call connection and just after call disconnection. Hylafax seems to issue at#cid=10 only after the call ends.

Ah, maybe it was AT#CID=10 and not AT+VRID. This is something you'll want to investigate. The fact that AT#CID=10 is being issued in the wrong moment is likely because you've got it on the wrong configuration item.



____________________ HylaFAX(tm) Users Mailing List _______________________ To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*

Project hosted by iFAX Solutions