Re: [hylafax-users] Question about Hylafax and Multiple Users

[Uwe Dippel <udippel@xxxxxxxxx>]

Lee Howard wrote:

> Michael Elliott wrote:
>
> > I didn't know if there was something in the application that 
> > attempted OCR on the incoming fax cover looking for "To:" and relayed 
> > that to an email.
>
>
>
> There are lots of different ways commonly used for routing incoming 
> faxes.  A few years ago I wrote a whitepaper on this topic for iFAX 
> that they have on-line here:
>
> http://www.ifax.com/component/option,com_docman/task,doc_download/gid,7/Itemid,97/

Thanks for the link !

> And it's still a relevant, verbose, document on the subject although I 
> probably would add or expand a few things...
>
> Two-stage dialing seems rather popular in some parts of the world.  
> Two-stage dialing involves a sender dialing a fax number, hearing a 
> message to dial an extension, and then dialing the desired extension, 
> and then starting the fax.  Many of the fax machines that I've used 
> wouldn't support this, I don't think, but maybe that's one reason why 
> it's not popular here.  In order to support two-stage dialing it 
> requires a bit of perhaps "tricky" HylaFAX configuration - first with 
> the SHIELDED_DTMF feature (for detecting dialed digits after 
> answering), and second with the <play:C> escape (in HylaFAX+ for 
> playing a dial-the-extension message).  In addition, the modem needs 
> to support DTMF detection, and that usually requires that the modem 
> support voice.
>
> Another method of inbound fax routing that isn't discussed in that 
> whitepaper is that of using distinctive ring (as someone else has 
> commented here on this thread).  Your telco can probably give you up 
> to 5 different rings on your line indicating which number was dialed - 
> sometimes also indicating whether or not the telco has detected it to 
> be a fax or data call (although I wouldn't rely on their detection 
> features).  So if you have a modem that supports distinctive ring and 
> you configure HylaFAX to handle it, you can route incoming faxes based 
> on the ring pattern that the telco presented.
>
> One drawback to OCR-based routing is that there does need to be a 
> fallback when the OCR fails to find any useful routing information on 
> the fax image.  Plus, if the routing information is not too dissimilar 
> between individuals (say you have an "melliot", "nelliot", and a 
> "relliot" as your routing information you may find that OCR will get 
> the routing wrong).  I tend to believe that bar-code OCR is more 
> reliable than trying to read-in text, but then that requires that your 
> senders use your barcodes - and for those that don't you still need a 
> fallback option.

This could become an endless loop, I know. On the other hand, it can 
advance the functionality and usage of hylafax pretty much, if we could 
route incoming faxes automagically.
Since we here want to apply the solution as general purpose solution, 
sorry to say, your suggestions are technically very sound, but 
unrealistic w.r.t. governance.
We need a solution available to anyone; without applying for two-stage 
dialling or distinctive rings. 5 different rings is no number, but a 
joke for a larger organisation. It is not possible to prescribe bar 
codes to our senders.
We do not believe in restrictive sender lists and neither in training 
(of OCR). Until now, we have (alas from a still rather small population) 
a recognition rate of e-mail addresses well above 90%; for 'fine' 
transmissions.
If you follow my earlier description, you'll see the fall-back route and 
the preliminary decision flow. If we can prevent > 90% of the faxes from 
being routed manually, we can save a lot.
a) when there is no " dot " and neither " at " on that single line, 
routing is not attempted.
b) if "melliot at server dot com" is read as "nelliot at server dot com" 
(not very probable with feature-based OCR), it will bounce back to 
FaxMaster as well.

No, I don't want to 'sell' our solution. But think of it, again. Once it 
is practicable and has a degree of robustness (I think it does already), 
routing is only one application. We could as well extract a filing 
number, customer id, reference instead. Simply through OCR of a defined 
region / block. Whereby the precision could only increase by 
'spell-checking' against the records of these numbers and ids; something 
we don't do for the email addresses.
We intend to use it as part of our documentation system; and there 
'fall-back' is definitively a tag 'unresolved e-mail' and 'bounced 
e-mail'. Which would be retrieval parameters in case of a document not 
found using the expected parameters (noisy transmission). When you have 
1 million documents to handle and a good 900.000 end up within the 
proper file or address; this is much, much better than 1 million 
documents that need to be handled and distributed manually. Because 
those not ending up at the correct destination can be identified easily. 
And still be handled manually; if one so desires.

Uwe


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