Re: [hylafax-users] Generating a Caller-ID only log file

[Aidan Van Dyk <aidan@xxxxxxxx>]

* Lee Howard <faxguy@xxxxxxxxxxxxxxxx> [060314 11:40]:
> Aidan Van Dyk wrote:
> 
> >Wouldn't it just make more sense to switch the order of isCIDOk, and the
> >DynamicConfig invocation?  This way, the DynamicConfig script could
> >change QualifyCID (as well as any other config option) based on the full
> >set of device/callid passed to it?  The patch looks big, but it's
> >basically just a cut-n-paste with changing an indent level.
> >
> 
> There are some types of call screening that are too exotic for 
> QualifyCID as it is.  For example, take screening calls based in part on 
> the time of day.  For example, take screening calls based on both 
> Caller*ID Name and Number.  Let's say that there is a single phone line 
> hooked up in serial with multiple modems ... with QualifyCID as it is 
> you cannot cause all but one of those modems to reject the call... but 
> by so doing you can, effectively, choose which modems are used to answer 
> which calls.  These kinds of things are just too exotic for QualifyCID 
> as it is.

Exactly.  But using your qualifycid-ex, you can't do that type of
screening based on device either (except for running different
qualifycid-ex scripts for each device).

> In order to do that kind of exotic call screening with DynamicConfig 
> running before QualifyCID you'd have to do something along the lines of 
> creating a temporary cid file that accomplishes what you need and then 
> setting QualifyCID to point to it instead.  It seems too difficult.

Sure - you need a different file,  But how bad is:
$SPOOL/etc/cid.accept:
	.
$SPOOL/etc/cid.reject:
	!.

And then it's another line that your DynamicConfig has to output.
	QualifyCID: etc/cid.reject
or 
	QualifyCID: etc/cid.accept

> DynamicConfig has been working off of a basis of only being run when a 
> call is going to be answered.  In some cases this may actually be the 
> desired behavior... to only do certain things if the call will be 
> answered.  With DynamicConfig running before QualifyCID, then 
> DynamicConfig would need to parse the QualifyCID file in order to make 
> this determination.  And yes, the downside is that this way 
> DynamicConfig cannot be run if the call will not be answered, but moving 
> it before QualifyCID is essentially exchanging one missing feature for 
> another.

You see - the point is that if DynamicConfig is changing QualifyCID, it
*knows* if the call is going to be answered or now. 

I actually was working off the assumption that dynamic config was being
run on *all* incoming calls - that it wasn't being run on calls being
reject was on oversite on my part - something that I probably would have
suggested fixing before.   Until I saw that setting QualifyCID had no
effect on the current call (only on the next call)...

And I think running DynamicConfig *before* the call is "answered" is
actually the correct thing to do.  For instance, it should be able to
change any configuration, one of them being the qualifycid that is used.

> Yes, I do feel that adding QualifyCID-Ex adds some bloat.  What I'd 
> really prefer would be to combine QualifyCID, DynamicConfig, and 
> QualifyCID-Ex all into one... essentially disposing of the Caller*ID 
> Number screening method currently used by QualifyCID.  That way the 
> resulting method will know which calls will be answered or not, and it 
> will be able to do all sorts of exotic call screening.  I didn't do this 
> because it seemed a bit too radical at the moment for me to want to do 
> independently, but if you're in favor of that approach, then I'm 
> certainly okay for it.  Trying to remain backwards-compatible for old 
> configs may be difficult or impossible, though.

I think taking exit status of DynamiConfig would be a better solution
than a separate script invocation.  But what about adding a "ANSWER:
REJECT|ACCEPT" line that it prints generates. That single line could easily
control the result of answering/rejecting, etc without needing a
backwards-incompatible change.  We could even only check that if
QualifyCID is not set if we're concerned about complete backwards
compatibility.

But, for the 4.2 series, I don't see backwards compatibility as a big
thing.  Unfortunately, we've played loose, and broken bigger things in
pushing features in..

-- 
Aidan Van Dyk                                             aidan@xxxxxxxx
Senior Software Developer                          +1 215 438-4638 x8103
iFAX Solutions, Inc.                                http://www.ifax.com/

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