HylaFAX The world's
most advanced open source fax server
Re: [hylafax-users] Generating a Caller-ID only log file
* 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:
And then it's another line that your DynamicConfig has to output.
> 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
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
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*