Hylafax Mailing List Archives

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

Re: [hylafax-users] ModemRingResponse



On 2004.03.05 11:01 Frank @ Impact wrote:
Lee, I noticed you were the one who posted the patch that included
this.

I read the docs I could on it. no archive posts.

It's infrequently used.


I have a modem that is setup with CIDNumberAnswerLength.   Works
great.
But the modem will sometimes be resetting itself and then miss the new
call RING and the DID info that comes in on the heals of the first
ring.
And it will therefore never answer that call.  Glare I guess.

Yeah, but if you rely upon DID for inbound routing this could be a nasty issue.


DID lines can be "busied-out". Look to see if you can utilize the AT commands to "busy-out" the line during resets to avoid this. I don't know if there are suitable places in the current initialization sequence to put these commands, though. It may require some code-work.

But the modem does have the ability to spit out the DID info on
command
(+VRID=10). My thought was to make this the ModemRingResponse so that
whenever the modem and hylafax finally do see the ring, it will also
be
seeing the DID string info that can then be captured by hylafax, the
CIDNumberAnswerLength satisfied and the phone answered.

But alas, things do not work out like this.


Mar  5 13:57:37 FX1 FaxGetty[24476]: --> [4:RING]
Mar  5 13:57:37 FX1 FaxGetty[24476]: <-- [11:AT+VRID=10\r]
Mar  5 13:57:37 FX1 FaxGetty[24476]: --> [12:NDID=8423722]
Mar  5 13:57:37 FX1 FaxGetty[24476]: --> [11:NMBR=<NONE>]
Mar  5 13:57:37 FX1 FaxGetty[24476]: --> [2:OK]
Mar  5 13:57:43 FX1 FaxGetty[24476]: --> [4:RING]

The problem here is that after issuing ModemRingResponse, HylaFAX sticks around in ClassModem::atCmd() waiting for the "OK" before continuing. Thus, the NDID and NMBR responses are ignored.


Note in the example on http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=374 that "OK" *precedes* the ID information. So it would be work as you desire if your modem did this instead:

 --> [4:RING]
 <-- [11:AT+VRID=10\r]
 --> [2:OK]
 --> [12:NDID=8423722]
 --> [11:NMBR=<NONE>]

... but that's backwards from how AT commands-and-responses are supposed to work. So maybe the ModemRingResponse feature is a bit too limited in its usefulness.

Around line 1305 of faxd/ClassModem.c++ you will see:

case AT_RING: // normal ring
if (conf.ringResponse != "")
// With the MT1932ZDX we must respond ATH1>DT1 in order
// to hear DTMF tones which are DID data, and we configure
// RingExtended to be FAXCNG to then trigger ATA.
atCmd(conf.ringResponse);
else
n--;
break;


if you change that to "atCmd(conf.ringResponse, AT_NOTHING);" then it won't wait for "OK". But, then you may (maybe not, let me know either way) have problems with this part of the same file around line 1002:

case AT_OK:
/*
* If we get OK and aren't expecting it then we're back in command-mode
* and our previous command failed to acheive the desired result.
*/
return (false);


See http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=460 on that. If you do run into this problem, then I don't know what the "right thing to do" to the code would be to accomodate things other than abandoning ModemRingResponse for your purpose and creating a new feature like "ModemRingFetchID" or something. It would be nice if that were not necessary. It would be nicer to extend ModemRingResponse without impairing its historical usefulness.

Lee.

____________________ 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@xxxxxxxxxxxx*



Home
Report any problems to webmaster@hylafax.org

HylaFAX is a trademark of Silicon Graphics Corporation.
Internet connectivity for hylafax.org is provided by:
VirtuALL Private Host Services