Re: [hylafax-users] ModemRingResponse

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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*