[hylafax-devel] Re: Supporting Digital Modems in HylaFAX.

[Steve Williams <steve@genie96.com>]

Hi,

I would like to commend you on the concept...

We are currently running 13 modems here, so hitting the T1 side of things 
in the forseeable future is not that unrealistic.

I have been on the HylaFAX developer list since 1994, doing the AIX port
of HylaFAX.

I know that it is possible to run over TCP/IP connections because I 
have seen notes from people that have run HylaFAX from terminal servers
using the solution:

> - Provide drivers so that modems inside a RAS appear as /dev/tty to
> HylaFAX. I've gone that way before and I know it is impossible for me
> (or to anybody) to support/maintain proprietary drivers for all OSes
> and OS versions adequately.
> 

One reason that running modems via TCP/Ip is not currently supported by 
HylaFAX has been concerns of robustness.  HylaFAX prides itself on being robust,
AND IT IS!!  Timing is very critical to successful faxing, and there have
been concerns expressed that there is no way to GUARANTEE timing issues when
using TCP/IP, because packets could get delayed on delivery, etc.

Please note, I do not have any personal experience in this area, so I am
quoting "hearsay".

With the timing necessary for Class 1 fax modems, I cannot imaging that it 
would be possible at all over TCP/IP in a production environment, which is
what you are talking about if it's a T1 environment.  I guess if the RAS box
was on a switch direct to the host, it would probably be fine, but random 
network traffice ( busy bursts ) could easily cause the fax to fail.

So, the first thing to ask would be... does your RAS box provide Class 2 or
Class 2.0 fax support?  If not, then I would think you should not even 
consider implementing the fax side of things.

The opening of a socket and sending AT commands ( & receiveing responses ) 
would actually be reasonably easy to implement in HylaFAX.  The problem is 
that HylaFAX ( and virtually every other comm package ) has been designed 
with SERIAL RS-232 communication to the modem.  Unfortunately, communication 
with the modem is not simply done through two file handles ( TX & RX ).  
There is other information sent via the other wires in the RS-232 spec.

This is the area of of signals being sent to the modem.  Currently, when the 
file descripter open on a "/dev/tty" type of interface is closed, DTR drops 
( by virtue of the Unix device driver ) and the phone line gets hung up 
( if wiring, modem, etc are configured 100 % ).  

There are many controls that are set by ioctl commands ( such as baud rate, 
flow control, clocal, etc ).  By using a socket interface, an entirely 
different mechanism would have to be engineered to transfer the information 
to the modem.... ( Humm, re-reading that, how much of that information is 
actually relevant??  flow control, for sure, but the rest... )

A simple example...

To access a modem under Unix:

  open() command with O_NONBLOCK so that the open doesn't hang.  
  set CLOCAL on the port so that CD the state of CD is ignored 
  clear O_NONBLOCK so that a read() command WILL block until data is available
  dial the modem
  wait for the CONNECT message
  clear CLOCAL so that a read() will return EOF when CD is dropped
 
  ( I'm working from memory, so forgive me if I missed a step )

Each step along the way serves a very specific purpose.

Trying to provide the same level of functionality ( ie: non/blocking open, 
blocking reads, nonblocking reads, sense of loss of carrier ) through 
sockets is ( I believe ) a non-trivial issue.

Close isn't good enough, it has to work 100 % of the time, regardless of 
network load.

I am sorry if I am talking at a very "obvious" level with you, I am just
being clear in case you don't already know all of the above stuff.....
( and rambling a wee bit, I have noticed )..

I am not aware of any "standards" to accomplish what you want, but really,
that doesn't mean much, I don't exactly have my ear to the door on this 
particular subject.  As much as I hate to say it, do you plan on your
product being supported under Windows ( NT/2000 )?  If so, then the place
to start might be with standards for support faxing over TCP/IP in that 
environment, and see how realistic they would be to implement in the Unix 
environment.

You might consider trying to contact demon.co.uk ( think that is the domain )..
They are providing fax coverage for most of England through the TPC.INT 
network ( www.tpc.int ) using HylaFAX.  I am not sure what they are running for
hardware, but it must be pretty beefy stuff given the volume that they process.

Someone on this list might know the contact, I can't seem to hunt it up..

You could always try faxmaster@demon.co.uk & see what the turns up..

Anyway, I've spewed on enought for now.

Good Luck,
-- 
	Steve Williams, Calgary, Alberta, Canada
	Genie Computer Systems Inc.
	steve@genie96.com

"A man doesn't begin to attain wisdom until he recognizes that he is 
 no longer indispensable."
- Admiral Richard E. Byrd ( 1888-1957 )
> 
> 
> Hello.
> 
> Thanks for the replies to my message.
> 
> Nico wrote:
> > Whoof! We *like* you! And it's a very good question. Let's see:
> > HylaFAX runs on UNIX: the RAS box therefore must be an honest-to-ghu
> > UNIX box, with ghostscript, libtiff, and some other packages
> > installed.  I suspect you don't want to go there, although if it's
> > actually Linux or another UNIX at its core it may be feasible.
> 
> Maybe my explanation yesterday was not very clear. I'm *not* planning
> to:
> 
> - Run HylaFAX or a fax server inside the RAS. That could be possible,
> but is not trivial.
> 
> - Provide drivers so that modems inside a RAS appear as /dev/tty to
> HylaFAX. I've gone that way before and I know it is impossible for me
> (or to anybody) to support/maintain proprietary drivers for all OSes
> and OS versions adequately.
> 
> What I *am* thinking about doing:
> 
> Provide a TCP-socket based interface in the digital RAS box so than an
> application can open a socket (instead of opening a /dev/tty), connect
> to the modems. We would also provide "AT session" emulation, so that
> they look like regular modems.
> 
> That would require HylaFAX to support a new "class" of fax-modem that
> is socket-attached (not tty-attached). I immagine that, while this is
> not specially difficult, there is considerable work (in both the RAS
> and application) to make that happen.
> 
> Because this solution uses TCP-socket (which is standard) instead of
> proprietary tty-emulation drivers, it would require less OS-related
> maintenance and would allow different applications and modem servers
> to interoperate freely. I believe that is a better long-term solution
> than TTY emulation.
> 
> The questions I have:
> 
> 1) Is there enough demand for fax-over-T1 (in other words, is there
> enough people using fax with 16+ phone lines at one location?) to
> justify the effort?
> 
> 2) Does anybody (a) see a problem with the solution proposed above?
> (b) know of a better solution? I'm not sure this solution can address
> fax reception properly.
> 
> At this point, I want to verify (1) and, provided there is enough
> motivation, discuss (2). I don't know much about HylaFAX architecture
> and fax protocols and I'll need help there.
> 
> Regards,
> 
> Marcio. 
> 
> --
> _________________________________________________________
> 
> Marcio Saito
> Director of Technology
> voice (510) 770-9727 x214  mailto:marcio@cyclades.com
> Cyclades Corporation http://www.cyclades.com
> _________________________________________________________
>