SDK 6.7.2 is the latest Brooktrout development kit providing feature rich capabilities to our partners. In addition to the normal assortment of bug fixes, 6.7.2 also has added some new features that will be quite useful. I’m going to focus on a few of them here, over several blog posts, to give more details on why they can help you. This is the second of three blog posts.
DIS stands for Digital Information Signal and it is the message a receiving fax device uses to tell the sending side what fax capabilities it has (what the receiver CAN do). The sending device responds with a DCS message (Digital Command Signal) which says what fax parameters WILL be used based on the capabilities in the DIS.
One condition that’s been a thorn in our side is that sometimes we’ll see the DIS information get changed. The Brooktrout side will receive a DIS message and will respond with the DCS as normal. After that though, the other side will send another DIS but with changed capability information. The remote side is not supposed to change the DIS, and it’s not clear why it happens. It may be that there is something else on the end-to-end connection like an IP gateway that’s doing this.
Whatever the root cause is, up until now, the Brooktrout side would reject such a situation with a hangup code of 33 – “Incompatible fax formats”. Obviously, it’s not a great thing to not be able to send a fax across, so to make the Brooktrout side more robust some DIS changes will be allowed. The important thing is where the change to the DIS occurs. If the change occurs in the higher DIS capability bytes (higher than byte 4), no error will occur and the fax will proceed as normal. If the change does occur in the first four capability bytes then hangup 33 will still happen. The reason for this is the first four bytes contain the most important capabilities: compression, page width, resolution, and Error Correction Mode (ECM) capability.
Let’s take a look at an example. This comes from our own debug log. The first case shows the behavior prior to SDK 6.7.2. The first DIS message comes in with bytes “ff 13 80 00 ee f8 c4 80 10 78 77”. The bytes “00 ee f8 c4 80 10” are the capability bytes and the other bytes simply identify the message as a DIS and make sure that it was received properly. The Brooktrout side sends its DCS, but then a changed DIS arrives. There is a message identifying which byte had changed and the hangup 33 is generated.
02/23 16:13:05.73 1[41,3] < ff 13 80 00 ee f8 c4 80 10 78 7702/23 16:13:05.73 1[41,3] DIS Digital identification signal
02/23 16:13:05.87 1[41,3] > ff 13 83 00 22 f8 44 00 0002/23 16:13:05.87 1[41,3] DCS Digital command signal
02/23 16:13:22.89 1[41,3] < ff 13 80 00 ee f8 44 1f 6902/23 16:13:22.89 1[41,3] DIS Digital identification signal02/23 16:13:22.92 1[41,3] < (09) FAX (08) EVENT (7D) DIAGNOSTIC_REPORT (7C) DIAGNOSTIC_MESSAGE [10: Fix Uns Byte Char] "DIS has changed: new=44 old=C4
If your application prints out long error codes, you would also see something like this:
BfvFaxEndOfDocument: Hangup: Incompatible fax formats, e.g. page width. (33)
Now with SDK 6.7.2, the same DIS messages will come in, but this time the SR140 will not reject them.
02/23 15:58:26.92 55[41,3] < ff 13 80 00 ee f8 c4 80 10 78 7702/23 15:58:26.92 55[41,3] DIS Digital identification signal
02/23 15:58:27.05 55[41,3] > ff 13 83 00 22 f8 44 00 0002/23 15:58:27.05 55[41,3] DCS Digital command signal
02/23 15:58:44.13 55[41,3] < ff 13 80 00 ee f8 44 1f 6902/23 15:58:44.13 55[41,3] DIS Digital identification signal
02/23 15:58:44.27 55[41,3] > ff 13 83 00 22 f8 44 00 0002/23 15:58:44.27 55[41,3] DCS Digital command signal
The DCS is sent as normal. The byte that was changed with the fifth one and so the new feature allows this change.
But wait, there’s more. I said if the change occurs in the first four bytes, the error would still occur. However, those four most important capabilities - compression, page width, resolution, and Error Correction Mode (ECM) capability – can be changed in a second DIS message if they would not affect the capabilities the Brooktrout side was already using. Let me say that a different way. Say for example, the first DIS allows MMR compression and the second DIS allows only MH compression. If the Brooktrout side was already set up to use just MH compression then this scenario would work fine. The DIS did change, but the change didn't prevent the Brooktrout side from doing what it had planned to do.
We used SDK-6.7.3 as a sender and were already transmitting the first page, when we received both NSF and DIS after 10 seconds a second time with identic parameter. The SDK issued error 33, as mentioned above.
I would have expected that either the FSK signals get ignored (as they did not change), or that a differnt error code would have been chosen. Maybe a code that suggests that the receiver does not "hear" the sender or such.
From what you've described it would sound like something else was going on. Please enter a support case with us at firstname.lastname@example.org and we can investigate.
Also, just to mention, the Brooktrout products do not actually do anything with the NSF information other than to make it available to the host application. No protocol decisions or errors would occur because of the NSF information.