HylaFAX The world's most advanced open source fax server

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

Re: [hylafax-users] routing received faxes to clients



On 2004.07.06 10:29 Bill Binko wrote:

Lee,


  You are (as usual) right about DID being the best way to do this.
However, I have tried to make that sale to a small business client,
and
it's a high hurdle.  In many cases, it involves switching at least
phone
plans, and in his case phone companies.  It simply wasn't worth the
effort.

I've investigated analog DID services for clients between three different telcos. All three of the telcos (Qwest, Sprint, Pacific Lightnet) offered analog DID service at around $40-50 per month per trunk/line. Pricing on "blocks" of DID numbers varied significantly (between $5-20 per month per 20), but not enough to make it notably expensive. The MT5634ZBA-DID modem is roughly $400, and one is used for each line/trunk. So that's the "expensive" part of it, but it's certainly less than purchasing a new multiport modem, and it's far less than moving the client from analog to digital systems and having them purchase digital equipment. (Of course, once you talk about more than about 4-5 lines/trunks, then digital becomes the more economic solution.)


So, basically for an initial investment of $500 and a monthly recurring fee of less than $100 you can accomplish a very attractive solution: routing faxes solely based on the number that the sender dialed. The sender can be trusted to do that, because they can dial a number already as a minimum expectation.

Now, certainly there are "cheaper" solutions to this; OCR and subaddressing are a couple of these. However, except for the case where the routing needs to be virtually dynamic (i.e., the routes are not static), or there are an enormous amount (i.e. several hundred) of routing possibilities, I can't think of a situation where any solution is going to be better for the users than DID. The problem with subaddressing is that many fax machines can't send subaddresses, and even then it may be difficult to educate those who send you faxes on how to use subaddressing. So, really, unless you can control both the sender and receiver yourself, it's very difficult to make subaddressing work ideally. Now, I've never used OCR, but it would seem to me that the problem with OCR-based routing would be tightly tied with the limitations of OCR. (I.e., let's say the sender doesn't have ECM on their fax machine, and the bar code/key routing text on the page gets garbled, but not enough to trigger RTN... then your receiver will respond with an MCF confirmation, and how does the fax then get routed? Or lets say the sender fed the page in crooked... can the OCR software decode a crooked barcode?)

I'm not trying to say that everyone is wrong for trying to do things economically. I'm not saying that there isn't a place for non-DID routing mechanisms. What I am saying is that I suspect that nine of ten inbound routing mechanism needs can be satisfied best with DID, and the investment in it will be well-made.

  I hope I don't move this off-topic, but right now, we're primarily
concerned with routing faxed-in applications.  These are on our
standard
forms, and it is very possible for us to "force"  them to send in apps
on
our forms (we already do for regulatory reasons).

But this doesn't necessarily guarantee that the faxes you receive will be legible by the OCR program - while they still will probably be legible to a human. That human can be the sender.


  I have floated the idea of barcoding through my customer, and they
love
the idea.  However, after searching the archive, I have found little
help
(Basically, one guy said he found a $50 solution.... but didn't post
it
:(  ).

Lee, do you have any experience with this?

I don't have any use-experience with received-fax barcode scanning or received-fax OCR.


There seems to be plenty of potential, if that's what you've not been able to find:

http://jocr.sourceforge.net/
http://barcode.sourceforge.net/

I know you have settled
on
DID for your current application, but perhaps you have a trail you've
given up on that I could pick up?

Well, technically it wasn't *my* application, but my clients' applications, but yes, I found DID (or a multi-line/modem installation) to be a better fit.


(It would be VERY nice to route
inbound
apps to the processor for the right state.  I know that sounds minor,
but
it really isn't in this case.)

50 states = 50 DIDs. ;-)


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*




Project hosted by iFAX Solutions