BladeWare Email-to-Fax (E2F) is a BladeWare application that receives subscriber emails with either PDF or TIFF-F image-file attachments and faxes them to the indicated recipient. E2F also provides call detail, SNMP, CDR, and Web-based management interfaces.
BladeWare is a value-adding HMP server licensed to telecom-equipment OEMs and system developers to enable FoIP-based network and enterprise voice and fax services. E2F is a client application that uses BladeWare’s Open Telecommunications FrameworkÒ (OTF) Kernel API to send faxes using Multi-Modal Terminating Fax (MMTF). MMTF includes support for both T.38 and G.711 pass-through fax.
E2F Features
- TerminatingT38
- G.711 pass-through
- 200-port per server
- Subscriber database lookup
- IMAP interface
- SMTP support
- SNMP & SNMP alerts
- Call Detail Records (CDR)
- High-availability fault management
- Host media processing
- No specialized hardware required
- SIP call control
- Extensible client-server architecture
- Web-based administration
- Low power utilization
- Small footprint
- Linux based, all-software product
E2F Benefits
- Service differentiation and revenue
increase with fax feature - Interoperate with all gateways
- Lowest cost per port
- Ease of provisioning
- Control of product platform
- Low operating cost
- Developer control of system
BladeWare E2F Application
The E2F application is composed of three major subsystems: In-bound Email Process (IEP), Out-Bound Email Process (OEP), and Fax Control Process (FCP). These subsystems are implemented as threads in a single executable.
Inbound Emails
The IEP monitors a dedicated email account for incoming emails to the service. For each new email, the IEP downloads the email text and the attachment. It then attempts to parse the text to locate any required and optional fields. If the optional subscriber database is configured, the subscriber’s record is retrieved and used to populate parameters not present in the text. If the request is well-formed, a record is written to the Pending Operations Database (POD) and an acknowledgement (ACK) email request is queued in the Result Queue Database RQD).
If there is a problem with the request a NAK is scheduled in the POD.
If the request is valid the cover sheet is generated and attached to the request. The completed entry is then placed on the POD and scheduled for transmission.
Once an entry is successfully made on one of the queues, the subscriber email is moved to the in-process folder on the external mail server. If the Fax Control Process (FCP) has available channels the IEP attempts to process another email message as previously described. If FCP is busy, the IEP suspends, waiting for a signal from the FCP.
The email requests remain on the external email server until the request is successfully processed either by NAK or a result message being sent to the subscriber.
Subscriber Database
The database look-up package interfaces with the subscriber database via a SOAP library, but the developer can easily substitute another access method. The subscriber database, in its simplest form, can be a comma delimited text file.
Fax Control Process (FCP)
The FCP handles the actual fax operation. When a channel becomes available, the FCP examines the POD queue in memory for the oldest scheduled request. If an entry exists, the request is assigned to the free channel and the start transaction is posted to that channel.
The BladeWare thread handles placing the call and sending the fax. If the operation succeeds, an entry is placed in the Result Queue Database (RQD). If the operation fails and this is the first attempt, a First-Attempt-Failed email is queued to the POD. If the operation fails more than once but less than the maximum, the operation is scheduled for another attempt based on the retry delay in the configuration file. If the operation has failed and the maximum number of tries has been reached, a Failed email is queued to the RQD. If a request was queued to the RQD, a semaphore is cleared to request the Out-Bound Email Process to run and send the result message.
Outbound Emails
The Outbound Email Process (OEP) processes entries contained in the RQD. For each request in the RQD, the result email is formatted based on the appropriate result template (NAK, First-Fail, Failed or Completed) and sent to the subscriber. A CDR record is written for Failed, Completed or NAK’ed requests. Once the email is successfully sent and the CDR written, the OEP uses the IMAP interface to remove the request from the email server. Once the email has been deleted from the server, the item is removed from the RQD.
SNMP
The SNMP Agent runs a thread that answers SNMP requests with the use of an SNMP library. It implements the Management Information Base (MIB) defined by Commetrex for the Email2Fax system. A separate thread runs a trap package that provides an API for sending alerts.
High-Availability Feature
The Fault Detection Package (FDP) provides the facility for the E2Fax package to handle basic fault tolerance. The E2Fax servers operate in a cooperative cluster. They communicate via UDP messages between themselves. Each server is in one of three modes: Primary, Tentative, and Secondary. Secondary servers are backups that are idle. Tentative servers are attempting to become Primary due to the suspected failure of a Primary. Primary servers handle subscriber requests. At startup the FDP is placed in the secondary mode.
All Primary- and Tentative-mode servers send “I-am-here” messages periodically to all other servers in the cluster. All E2Fax servers, regardless of operating mode, collect “I-am-here” messages for a configurable period. After that period, the number of unique addresses is tabulated to build a list of Primary servers. If the local server is a Primary or Tentative mode server it adds its own address to the list. If this list is less than the number of allowed Primary servers, all Primary and Tentative servers remain or become Primary. All secondary servers become Tentative.
If this list contains more than the allowed number of Primary servers, Secondary mode servers do nothing. Tentative and Primary Servers sort the list. If N primary servers are allowed, the N lowest numeric IP:Port addresses are selected. If a server’s IP:Port is on the list, it remains or becomes Primary. If not it reverts to Secondary mode.
When a server is demoted to secondary mode, it does not immediately stop operation. The IEP function stops collecting new emails for processing. All existing POD and RQD entries are processed to completion before the E2Fax server stops operation. In this quiesced state, only the FDP, SNMP and WEB packages are operational.
Web-Based Status Monitoring
The Web server provides a Web-based status-monitoring facility. It provides channel status, and queue sizes. It provides commands to start, stop and suspend the operations of the Email2Fax package.