Faxing and machine-to-machine communications in the IP-based telephony age

The new direction for telephony

There is a new direction for telephony that will be affecting faxing and machine-to-machine communications over the next few years. It is Voice-over-IP which is regular voice telephony carried over an Internet-standard network.

This has been used primarily in large-business telephony but is now becoming a reality with consumers and small organisations. Initially, this technology was being pitched as a way of saving money on long-distance calls but is now becoming part of regular landline telephony.

The main drivers for this direction are the arrival of “naked DSL” Internet services where the telephone wires are used for DSL Internet connection and the customer doesn’t pay the incumbent telephone company for landline telephone service; cable-TV providers stepping to the fore for providing competitive local telephony service; and and the arrival of “single-pipe triple-play” services with multi-channel TV, Internet service and landline telephony delivered over one physical connection as one service package. These services are using the VoIP telephony technology to provide the local landline telephone service.

The next driver that will affect all customers is the national landline telephone system being moved away from the traditional circuit-driven setup to a packet-driven Internet-technology setup. Examples of this are the 21CN project in the United Kingdom and the National Broadband Network project in Australia. The advantage of these projects is to reduce the cost of providing regular voice telephony over short or long distances and to prepare for improved telephony setups like HD wideband voice telephony and video telephony. 

The effect on machine-to-machine applications

This will place a negative effect on machine-to-machine applications like faxing and monitored-alarm setups which are the two main applications that are facing consumers and small organisations. These setups are based on modem-based protocols that are designed for circuit-switched telephone networks like the “plain old telephone service”.

The main effect of this is that the packet-based telephony setups will cause the protocols used in these applications to go “out of step” and lead to communication failure. In the case of a fax machine, the document will either take a long time to go through to the correspondent or the fax transmission won’t succeed. In a monitored-alarm setup, the alarm event that is initiated by the premises-based alarm system will take a long time to register with the monitoring station or at worst won’t register there at all, which is a threat to security and safety – the main reason for these systems in the first place.

Bringing these applications to the IP age

Faxing

The T.37 Fax-over-email solution

Most high-end business-market fax machines are equipped to work according to the T.37 “fax-over-email” protocol. This is a “store-and-forward” method that uses regular SMTP and POP3 Internet email protocols to send hardcopy faxes as TIFF-F (fax-optimised TIFF) image files attached to emails.

This solution requires that the recipient has a T.37-compliant fax machine or computer which is running an email client and software for reading TIFF-F files to receive the files. This may be no mean feat for a general-purpose desktop or laptop computer hut most smartphones and similar devices won’t have software that can read TIFF-F files.  As well, a person can use a scanner attached to a general-purpose computer that has software that can turn out TIFF-F files from the scanner as well as the regular email client to send hardcopy documents to a T.37 fax machine.

Some T.37-compliant fax machines can be set up to work as a T.37 – G3 gateway to forward faxes to regular fax machines. But this requires the sender to send email to an address formatted as “fax-mailbox@service-domail(FAX#fax_number)”, which can be difficult with many popular email clients. Here, these clients may not handle the phone-number data that is held in parenthesis properly or require the user to “go through hoops” to support this function when they manage their address book. It may be easier if the gateway uses a “international-format-fax-number@fax-gateway.service-domain” address format.

As well, the technology could support colour or greyscale photographic images through the use of JPEG or a colour variant of TIFF-F. This point is raised because of most fax-enabled inkjet and colour-laser multi-function printers being equipped with the ability to send and receive colour faxes using the “Super G3” protocol.

The T.38 real-time-fax solution

The T.38 protocol has been introduced as a method of providing “there-and-then” fax transmission over an IP network. At the moment, it requires a gateway device to be connected to a regular fax machine at each end of the link. This could be achieved by the use of a properly-designed VoIP “analogue telephone adaptor” terminal that becomes a T.38 gateway when it is connected to a regular fax machine.

The standard also requires the use of SIP and other call-setup protocols that are used in VoIP to establish the call. The destination information would have to be understood by the gateway picking up the DTMF “touch-tones” from the connected fax machine.

You can use a single ATA for VoIP and T.38 service, with use of distinctive ring + CNG fax tone to “wake up” client fax for incoming calls and use of the CNG fax tone generated by the connected fax machine to enter T.38 mode. But this would require separate T.38 service with separate number to be provisioned for smooth operation.

Another question is whether a network-enabled fax machine can become a T.38 fax endpoint machine or not? As well, would the T.38 protocol support enhanced fax modes like “photo” resolution or colour faxing.

What can be done

Improved provisioning experience

At the moment, most mid-tier consumer and all business multifunction printers have regular fax functionality and network connectivity. As well, some small-business units, especially the units sold by Brother, have T.37 “fax-over-email” functionality as part of the function set.

Typically these features are difficult to provision and use for most home and small-business users. What could be done is to implement a “wizard-based” user experience for the provisioning routine and / or, there could be the ability to download an XML provisioning file from the Internet provider whenever one wants to set up Internet fax.

As well, the industry could adopt a qualification program for Internet-fax equipment that requires a unit to achieve certain requirements such as compliance with known standards before being able to receive the right to display a particular logo of compatibility. This could also extend to the use of service-information files provided by carriers and service providers so that there is little effort required on the behalf of the home or small-business customer to set up their Internet fax service.

Internet fax service as part of a communication service provider’s arsenal

As far as addresses for T.37 fax services go, there could be the ability for a subscriber to be provided with a “virtual fax number” as well as an email address for their T.37 service. This is a telephone number that a person can dial to send faxes to the T.37 mailbox from the regular fax machine. Similarly, there could be support for an SMTP fax-gateway setup that uses a simplified addressing scheme as I have outlined earlier but uses address and password protection to authenticate customers and these would then be related to the “virtual fax number” which is to show on a regular fax machine’s display and  in the fax transmission reports.

The T.38 real-time-fax service could simply be provided by a VoIP or triple-play communications provider as a secondary fax-only number which works with T.38-compliant fax gateways or endpoints. This could be provided with a T.37-compliant Internet fax mailbox that can lead to such services as controlled transmission or reception setups such as “receive all faxes when you start business” or “transmit international faxes I send on local morning time”.

Equipment and software design considerations

A network-enabled fax terminal should support both the T.37 and T.38 network-fax protocols as well as the Super G3 protocols for circuit-based communications. As well, the setup experience for these machines should be simplified, preferably wizard-driven and with service-host interaction, so that people who don’t have much computer experience can get these machines going for Internet fax. This can be augmented by support for standardised XML-based service-manifest files that are downloaded from the service host.

The same machines could also support the storage of fax addresses as regular numbers or Internet-format email addresses and could simplify the construction of Internet-based fax addresses for regular number-based addresses based on however the T.37 fax server expects such addresses to be formed. This should then simplify the management of the one-touch or speed-dial address book that is part of the typical fax machine’s feature set. As well, email software should support the ability to send and view T.37 fax-over-email messages and support “sub-addressing” and address construction for T.37 fax gateway servers.

Monitored alarms

The main method that is being used for adapting an existing  monitored alarm infrastructure to an IP-based environment is to use a VoIP analogue-telephony-adaptor terminal that is programmed to be a “virtual modem” endpoint. Here, the alarm uses the standard modem protocol to signal the event to the ATA and this device forwards the event message to the control centre using an industry-standard message packet.

On the other hand, a network-enabled alarm system could be connected to the network and sends the event message via its network interface. This also includes existing systems that are designed to be future-proof by allowing a network interface kit to be installed at a later date.

There will also be the desire to provide this kind of network integration to this class of device in order to support enhanced monitoring functionality or building automation. The latter application would bode well with the “green impetus” in order to provide functionality such as synchronised control of lighting and heating / air-conditioning.

Another benefit is that a monitored alarm setup can be upgraded with new firmware without the need for a technician to visit the installation. This is in the same way that computers and mobile phones can be “patched” with software fixes by them connecting to a server to get the necessary software.

What needs to happen

Customers need to know what to do concerning evolving their monitored security or safety services to the Internet-driven world and view it as being important for all such services, not just for high-perceived-risk installations. As well, any monitored-alarm equipment that is pitched at the residential or small-business user has to have inherent IP-based monitoring or have support for the feature at a later date.

Equipment design considerations

The alarm-system industry needs to provide panels that either have inherent support for IP-based  signalling or can be upgraded to this function at a minimal cost through its service life. This is understanding that a typical alarm installation is seen by its users as a “backbone” device in the same context as a central-heating boiler or furnace and is therefore expected to have a service life of at least 10 or more years.

This should mean that a hardware upgrade should be in the form of a card being installed in to the existing alarm panel or a software upgrade is provisioned by, at the most, one visit from a technician.

Conclusion

As telephony systems move towards the packet-driven IP telephony space, the traditional machine-to-machine applications that face most users need to be evolved to support the Internet-based networks. This includes improved in the way these services are set up so that most people can provision them in a competitive manner rather than being tied to a particular carrier or operator.

Send to Kindle

Latest Comments

  1. Pedro Neves 03/01/2012
  2. simonmackay 03/01/2012
  3. Pedro Neves 07/01/2012
  4. Pedro Neves 07/01/2012
  5. Pedro Neves 08/01/2012
  6. sergei 05/04/2015

Leave a Reply

*