Page Comparison

Lower end customers are looking to get away from having a dedicated phone line for their fax server.  The TR1034 board also requires a physical server.  These customers are looking to move to a service base deployment for the following benefits.

...

Output Parameter Description

...

 Exploring with JIRA

======================================================================
There are at least 4 ways to approach supporting other third-party fax APIlibraries within the Bfv API.
1) Create a new library that implements all Bfv API functions using the thirdparty API in some fashion. This would mean having a different library thatexports all the same functions as the regular Bfv API library. It would thenbe independent of the regular Bfv API library, and would suffer frommaintenance issues. Applications would have to include a different header fileand link with a different library. The two libraries could not be usedtogether.
2) Create a library as in #1, but with functions which have distinct namesfrom from those of the regular Bfv API library. Create a series of macroswhich map from Bfv API function names to the names used in the other library.Applications would have to include a different header file and link with adifferent library. This would be similar to how the Centennial and MillennialBfv API libraries both use the same interface and can even be used together inthe same program. It would also suffer from maintenance issues.
3) Extend the Bfv API library to support additional "fake" channel types whichare implemented in terms of an external third party library.  Depending uponhow a channel attach is performed, it could either attach a channel in thestandard fashion or it could create a "fake" channel, and have all Bfv APIcalls that use such a channel call different functions at low levels. Itshould not suffer from most maintenance issues, since whenever a new featureis added, if channels are not involved, then no extra work should needed, andif they are, the fake channel types would be required to to be handled, too, ifapplicable, at that time.
4) Make a modified SR140 which accepts firmware commands and performsappropriate actions using the third party library, and create appropriatefirmware responses. Almost all changes would be hidden from the API level,but would probably be very complex to implmement.
I will be assuming that #3 will be the way we will choose to implement thethird-party fax API library support.

============================================================
To further expand on #3, we need BfvLineAttach to be able to determinewhether it is attaching to a standard Brooktrout channel or a fake channel.
While it is possible that a single config file keyword could be used to turnall channels into fake channels, that would not be conducive tohaving the channel types coexist.
More flexible would be a variation of this that allows specification of whatchannels should be attached as fake channels. E.g.
third_party_nonrt <third party shared lib> <lower channel> <upper channel>
This is still somewhat limiting, since it may require knowing something abouthow many Brooktrout channels there are in advance.
If <upper channel> is not specified, then there would be no upper limit.  If<lower channel> is not specified, then it would default to 0, and all attacheswould be fake channel attaches.
The channels would seem to have a new module number (0x90?) that is notcurrently assigned for any purpose and machine 1. Such module and machinenumbers are really meaningless, since there would be no communication with theBrooktrout driver for these channels. There would be a limit of approximately250 channels of this type due to the addressing format.
======================================================================
Various remarks:
In caps.h, where Bfv API capabilities are defined, we would add two newcapabilities, CAP_CHANNEL_BRKT, and CAP_CHANNEL_3RDPARTY_NONRT.CAP_CHANNEL_BRKT would be set for all standard attaches.CAP_CHANNEL_3RDPARTY_NONRT would be set for channels in the range specified bythird_party_nonrt.  In case we ever have some other third party library of adifferent type, this could give us some flexibility. Additional othercapabilities may be added to help differentiation. These may be based oncontacting the remote server and receiving information on its capabilities.
At its lowest level, the Bfv API fax transmission and reception ultimatelyoperate on buffers of fax data. Because of this, the easiest format to usewith a third party non-realtime API would either be one big buffer of fax dataor a file containing fax data. Most non-realtime APIs operate on files in somepre-specified other format, such as TIFF. Whatever is the case, we would needto convert to/from this file type, and it would need to be done even if theoriginal fax data being sent is already in a file of that type.
The file format used by some of the non-realtime third party APIs hasbeen described as "TIFF", but it is unclear what type of TIFF file thisactually is - is it TIFF Class F, which contains MH, MR, or MMR fax datawithin it? Or some other type?
Because there is no true "number of channels" for utilizing a non-realtimeAPI, the number is what we say it is, which should be no more thanapproximately 250 channels.
When doing an operation (like the modinfo program) that queries the driverabout modules in use and their channels, the fake modules would not be seensince the driver knows nothing about them. (This might be doable differently,if we implement some shared memory region within bostsrv which is createdwhen bostsrv is run based on config keywords which can bequeried, but likely this is a needless complication.)
Phone calls, of course, don't actually happen. For inbound calls, we wouldperiodically poll the third party server until either a fax has arrived or anindication of a failed incoming call has arrived.  At this point we wouldreport an incoming call, and the fax data would be ready to returnimmediately, with fake T.30 negotations, etc.
For outgoing calls, since fax data is normally not supplied to the Bfv APIuntil after a call is successfully placed, we would have to pretend that allcalls are successful, supply fake T.30 negotations, and accept the data forsend. Only then could we initiate the non-realtime send. If there is a callfailure or fax transmission failure, we'd have to give an error of some sort,though it is no longer possible to report call placement errors at thatpoint. Before indicating the call placement has been successful, we couldpossibly verify that we can still contact the remote server first.
Line types for the fake channels would probably be reported as analog.
We will define a Fake API Interface Layer to interface to the third partynon-realtime APIs, similar to the CIPI layer used to interface to internetstacks. This is an abstraction layer that the Bfv API will call which hidesthe low level details of the actual third party software in use. A librarywill be written that implements the FAIL layer, including any necessaryinternet communication to talk to the third party non-realtime server.This is the library that will ultimately be loaded by the Bfv API.
The FAIL layer has yet to be defined, and will be the subject ofan additional proposal.