Hylafax Mailing List Archives

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

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



Aidan Van Dyk wrote:

* Lee Howard <faxguy@xxxxxxxxxxxxxxxx> [060314 11:40]:


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).



Nah, just like DynamicConfig the first argument to QualifyCID-Ex is the device name.


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



Sure it's easy for us... but I'm just not sure how obvious that will be for a newbie to conceive.


Furthermore, by doing it this way we essentially obsolete the old QualifyCID approach - this new approach being far more versatile, and we may as well abandon the old method, I think, if this is the case.

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



If DynamicConfig were always controlling QualifyCID then this would be true, otherwise not.


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.



There are other config items that DynamicConfig cannot control. For example, the CallID stuff, RingsBeforeAnswer, probably others.


I'm certainly not opposed to making DynamicConfig more versatile, however, by moving it ahead of isCIDok, but in doing that I believe that we should make DynamicConfig responsible for whether the call will be answered or not so that it can act accordingly - and remove any possibility of any uncontrolled QualifyCID setting from interfering there.

I think taking exit status of DynamiConfig would be a better solution
than a separate script invocation.


I'm fine with this, too.


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.


I'm fine with this, too.


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..



HylaFAX development has been far more concerned, over the years, with backwards compatibility than most other development projects that I know of. To me it's a good thing to have if it's easy to do, but otherwise, just move on and don't let that ambition create future confusion and problems. For something like this keeping backwards compatibility doesn't matter at all to me... but, like I said before, I wasn't really wanting to make that decision independently. But, take your pick of whatever of these options that I agree with, and let me know where to go with this.


Thanks,

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@xxxxxxxxx*



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