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.
Software Only Solution
The benefits of a software only fax solution removes the requirement to have a dedicated physical server for the fax server. By having a software only solution, the fax server could be deployed in a virtual environment either locally or cloud based.
No Dedicated Phone Line
By removing the physical phone line provided by the telco for the fax server, remove the monthly fee cost for a phone line that may or may not be used. The fax server is also not tied down to a physical location.
Pay for Usage
Customer would like to move from paying for a up front fax server with a defined number of channels to a service that can scale as needed.
Customers would like to keep their existing fax server application and would like to be able to use a fax service with their current setup. These customers are also willing to use a store and forward solution that the current FasS providers provide. The FaaS providers would like to deploy to the current Bfv based market. They have approached the application vendors to use their FaaS API.
Fax Service Layer
To direct traffic to a FaaS provider, the Bfv API would need to be aware of these FaaS API's. Would need to know what one it is to connect to. Customer Credentials to use the service. Know it is in FaaS mode and perform store and forward faxing.
Issues with FaaS
It is a store and forward solution.
Fax media processing is performed at the service location and is out of the control of Dialogic. Debugging issues would require the service provider to provide details back to the application on the error. Items like headers and fonts are no longer performed by the SR140 or TR1034 board. Bfv API functions that allow the application to make real-time decisions or provide protocol information may not be available. (T.30 Holdup)
Sample Service
FaxSIPit is an example of a FaaS vendor. They provide a REST based API that allows sending and receiving of faxes. The applciation will make a HTTPs request to the API and parse the responses. Their current format is JSON. It uses standard HTTP methods like GET And POST to access the service.
Send
This function is used to send a fax. The method used by this request is post and has the URL http://65.39.245.253/rest/1.0/api/send. It follows the Rest API calling conventions:
POST http://65.39.245.253/rest/1.0/api/send
Input Parameters
Input | Description |
---|---|
dialnumber | Destination number in the format 1+areacode+number |
callernumber | Specify the caller id |
csid | Calling station id |
faxfile | This field contains the document to send. Accepted format is tiff |
Output Parameter Description
Output | Description |
---|---|
RefCode | Unique code for the sent fax |
Status | Status of the sent fax |
Created | Time Shows the time the fax was created |
Example: Sending a fax to 17274568620
curl -X POST \
http://65.39.245.253/rest/1.0/api/send \
-H 'cache-control: no-cache' \
-H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
-F dialnumber=17274568620 \
-F callernumber=7274568620 \
-F 'csid=my fax' \
-F 'faxfile=@\\rsdbs3\Home\vijur\Desktop\test pages few\1p - CCITTTest.tif'
If successful response will include a file object as follows.
{"RefCode":"a4ba2090-8360-11e7-8717-513b01d011ef","DialNumber":"17274568620","CallerNumber":"727","CSID":"Viju Fax","Status":"Created","PagesDelivered":0,"ConnectTime":0,"ConnectSpeed":0,"RemoteId":null,"CreatedTime":"8/17/2017, 8:27:56 AM","CompletedTime":null}
Only TIFF documents can be uploaded. Sending any other format will generate the following response object:
{"Response”: “Failed to upload the file. You can upload tif or tiff file only."}
Outbox
This is used to check faxes that are in the process of being sent. The method used by this request is GET and has the URL http://65.39.245.253/rest/1.0/api/outbox
Output | Description |
---|---|
RefCode | Unique code for the sent fax |
Dialnumber | Shows the destination number |
Callernumber | Specify the caller id |
CSID | Calling station id |
Status | Shows the status of a fax |
Fax sent to 7274568620 is in sending status. Here is the response from the outbox command:
curl -X GET \
http://65.39.245.253/rest/1.0/api/outbox \
-H 'authorization: Basic dGVzdDp0ZXN0' \
-H 'cache-control: no-cache' \
Response:
{
"RefCode": "a4ba2090-8360-11e7-8717-513b01d011ef",
"DialNumber": "17274568620",
"CallerNumber": "727",
"CSID": "Viju Fax",
"Status": "Sending",
"PagesDelivered": 0,
"ConnectTime": 0,
"ConnectSpeed": 0,
"RemoteId": "",
"CompletedTime": null
}
The current FaxSIPit API document:
Etherfax also has a REST API for faxing (and secure doc transport) that focuses on encryption: https://docs.etherfax.net/
Information from :
From: Eli Mann [mailto:emann@faxsipit.com]
Sent: Thursday, March 15, 2018 8:24 PM
I have dug some information that I think might be indicative for usage. There is no end to the data mining we can do (sector, volume, other profiles) but at the high level these are strong enough statistics based on few thousands of end users. So Inbound (IO) and Outbound (OB) split traffic SD and revenues for the higher volume accounts (lower minute rate).
|
| IB | OB |
---|---|---|---|
Percent |
| 32% | 68% |
1 standard deviation minutes/month per 8 ports |
| 1000 | 2000 |
1 standard deviation minutes/month per 8 ports |
| 10000 | 7000 |
Port Count minimum |
| 2 | 2 |
Port Count maximum |
| 24 | 48 |
Monthly traffic charges @ high volume (under 100K minutes/month) |
| $ 200.00 | $ 140.00 |
I found that mid-size (8 ports) shows very consistent results while some of the larger users are specific application driven and shows skewed results.
Add Comment