Location : Commetrex Support & Development Site » FMS Release Notes 2.4.3 FMS Release Notes 2.4.3

FMS Release Notes 2.4.3

Commetrex BladeWare Fax Media Server Release Notes

These are the release notes for Bladeware FMS version 2.4.3. These notes chronicle all changes to Bladeware FMS important to an FMS user.

These notes use Windows OS path-nomenclatures. Where environment path-names are used in this document, Linux users should substitute %OTF_ROOT%\dir patterns with $OTF_ROOT/dir patterns to resolve path names.
Table 1: BW SIP Release Summary
VersionBug Numbers in This VersionBuild Date
2.4.3 792,813,814 09/24/2012
2.4.2785, 787, 793, 800, 803 08/20/2012

Table 2: Bug Summary
BugSummary DescriptionVersion
814New command line options added to FMS 2 to determine errored fax behavior 2.4.3
813New command line option for FMS 2 allows creation of additional error logs. 2.4.3
792Bladeware/FMS occasionally responds to inbound SIP calls 100 trying, then 183 session progress with no 200 OK. 2.4.3
803Feature - FMS removed from Bladeware installation packages 2.4.2
800fms2_app.exe does not call CTses_Stop( ) when channels are stopped via the web interface 2.4.2
793Under some fax failure conditions FMS reports zero length fax files being received 2.4.2
787Feature - fms2_app command line '-l logfile' option added to allow run-time logging to a file 2.4.2
785FMS flaw may cause "channel leaks", ultimately rejecting inbound calls with the "all channels busy code" when all available channels are exhausted 2.4.2

Table 3: Bug Details
814The -T option was added to allow control of FMS behavior when an errored fax is transmitted. Similarly, the -R option was added for errored receives. For both options: 0 - All complete but errored faxes are not categorized as an error and the fax is delivered. (default behavior as it was in BW 2.4.2) 1 - All errored faxes are categorized as an error. Error-ed transmitted faxes are reported as such in the SIP INFO messages. Error-ed received faxes are reported as such in the SIP INFO messages and no HTTP put is attempted.
813The -E command line option has been added to FMS 2 (fms2_app) application. When -E is specified, FMS will create two additional logs: 1) A binary synopsis of all failed fax calls. This binary synopsis file has the same structure as that of the fax synopsis file created by Bladeware, and may be rendered into a viewable form using the Bladeware utility %OTF_ROOT%\bin\printsyn. The synopsis file is OTF_ROOT%\bin\Logs\fms_p30_error_log.dat. 2) A text file containing the state/event/state transitions comprising the error-ed call. This file is %OTF_ROOT%\bin\Logs\fms_error_log.txt
803The FMS application binaries, source code and supporting files have been removed from the Bladeware MSI and Linux distributions.
800The fms2_app was not calling CTses_Stop( ) to properly cancel outstanding calls to CTscr_RequestGroup( ) when commanded to stop via the web interface. Failure to properly cancel would cause incoming calls that are delivered to "stopped" fms2_app channels to be ignored, resulting in an inbound call flow wherein the inbound call is answered with a 183 and no other SIP code - neither the typical 200 OK nor any failure code.
793Testing revealed that there are conditions under which a zero length and/or un-renderable fax may be received by fms2_app. The fms2_app was modified to detect and remove zero length or un-renderable faxes, and so report via SIP Info message to the controlling app server.
792On inbound calls where API calls to CTscr_AnswerCall( ) fail, FMS will sometimes call CTscr_DropCall( ) before receiving the completion event for the CTscr_AnswerCall( ). FMS calls CTscr_DropCall because of an unsolicited remote disconnect event. In these cases, if the SCR receives the client's CTscr_DropCall( ) at nearly coincident times with the arrival of the failed completion event from the CTscr_AnswerCall( ), the call tear down logic in the SCR fails. There are in fact, two separate issues here: 1) the FMS state machine should be changed to not react to remote disconnect events prior when waiting for the completion event for CTscr_AnswerCall(), 2) the SCR should be protected against such calls to CTscr_DropCall( ) by client applications. The first issue has been addressed by adding a state to the FMS state machine. This, by itself, will resolve this issue for FMS. The second issue will be addressed under a separate bugzilla number.
787The FMS2 application fms2_app was modified to allow run-time logs to be sent to a file. In addition, a time stamp was added to various logged messages.
785Under some fax failure conditions, the fms2_app's state machine was getting stuck indefinitely in the “RECEIVING” state (visible using the FMS web interface) waiting for a fax completion event that never arrives. The fms2_app was modified to use a Run time control (RTC) to send a stop command to the Fax resource controller when the SIP RSM indicates that the CCR has gone idle (the call has concluded). This results in the fax stopping, and returning a fax completion event to the fms2_app causing the fms2_app to correctly begin a call tear-down.

Online Users

5 online users