GDK System Features

• TIFF Capability
• Tag Fields Supported
• Filenaming Convention
• Received Faxes
• Multiple-Page Documents
• Controlling Next File Send Option
• Binary File Transfer
• Routing
• About the DTMF Capability
• How GDK Works With DTMF
• Using the DTMF Capability
• Direct Inward Dialing (DID)
• T-1 Digit Collection
• T.30 Subaddressing
• Recording Line Noise
• Transparent PRI Support

TIFF Capability

GDK supports Group 3 1-D and 2-D T.4, and Group 4 T.6 compression. The type of compression may be selected for both sending and receiving fax files on each fax channel individually. The selection is controlled by the following: GFXFORM, GFXSTWOD, GFXRT6, GFXRTWOD, GFXST6.

When sending files, GDK supports these formats:

• ASCII text
• TIFF Type 3
• TIFF Type 3 2-D
• TIFF Type 4
• PCX

The file format is determined by the header of the data.

Tag Fields Supported

GDK currently supports and produces the tags for the TIFF fields listed in
Table 1.

NOTE:

Only one TIFF strip is generated per fax page. Each page may be a separate, sequentially-named file or a multiple-image TIFF file.

Table 1. GDK TIFF Tags

Tag No.	Name	Data Type	Description
---1	ByteOrder	int2	Order of bytes: II (0x4949) = Intel; required for GDK MM (0x4D4D) = Motorola
254	NewSubFileType	long3	A 32-bit flag indicating the type of data contained in this subfile.
256	ImageWidth	long2	Number of pixels per scanline. 1728 for A4 or letter 2432 for A3 2048 for B4
257	ImageLength	long2	Number of scanlines in image.
258	BitsPerSample	unsigned2	Number of bits per pixel sample; only "1" for fax.
259	Compression	unsigned2	Type of compression. Possible values: 1 = no compression (not supported) 2 = CCITT G3 1-D, no EOL (not supported) 3 = CCITT 1-D, with EOL or 1-D/2-D combined 4 = CCITT G4 5 = LZW compression (not supported) 32773 = PackBits (not supported)
262	PhotoInterpret	unsigned3	Photometric interpretation. Possible values: 0 = black on white (Default) 1 = white on black 2 = RGB scheme (not supported)
266	FillOrder	unsigned2	Order of the image bits, in bytes. Possible values: 1 = most significant bits are filled first 2 = least significant bits are filled first (Default)
269	DocName	char3	The name of the document from which this image was scanned.
270	Description	char3	A comment about the image.
273	StripOffset	long2	For each strip, the byte offset of that strip with respect to the beginning of the TIFF file.
277	SamplesPerPixel	int2	Number of samples need to define a pixel. Possible values: 1 = monochromatic data (Default) 3 = color data (not supported)
278	RowsPerStrip	long2	Number of scanlines per strip. Multiple strips are not supported.
279	StripByteCounts	long2	Length of a strip.
282	X_Resolution	int2	Pixels per resolution unit in the horizontal direction. Default = 204.
283	Y_Resolution	int2	Pixels per resolution unit in the vertical direction. Default values: 98 = standard resolution 196 = fine resolution
286	OffsetX	long3	Offset of the left side of the image, with respect to the left side of the page, in Resolution Units.
287	OffsetY	long3	Offset of the top of the image, with respect to the top of the page, in Resolution Units.
292	Group3Options	long4	32-bit flag describing options. Possible bit values: 0 = 1-D compression used (Default) 1 = 2-D compression used 2 = uncompressed data may be used (not supported) 4 = guaranteed byte alignment
293	Group4Options	long5	32-bit flag describing options. Value must be zero.
296	ResolutionUnit	int3	Unit of measurement to be used with X_Resolution and Y_Resolution. Possible values: 1 = no unit of measurement (not supported) 2 = inches (Default) 3 = centimeters
297	CurrPageNum	int3	Page number and number of pages in a multiple-page file.
326	BadFaxLines	long3	Number of scanlines with an incorrect number of pixels (TIFF Class F).
327	CleanFaxData	int3	Describes how the data was cleaned. Possible values (TIFF Class F): 0 = data contains no lines with incorrect pixel counts or regenerated lines (Default) 1 = lines with incorrect pixel count were regenerated on receipt 2 = lines with incorrect pixel count existed, but were not regenerated by receiving device
328	ConsecutiveBad FaxLines	long3	Maximum number of consecutive fax lines that contain an incorrect number of pixels (TIFF Class F).

1 Not defined as a tag

2 Required for GDK

3 Optional

4 Recommended for compression 3 only (see TIFF Tag No. 259)

5 Recommended for compression 4 only (see TIFF Tag No. 259)

Filenaming Convention

GDK has a number of filenaming conventions, which depend on the type of file. The following discusses these conventions.

Received Faxes

A received fax file is given the following default name:

a001p001.tif, where "a001" is the fax-call number, "p001" is the page number of the document, and the extension "tif" indicates that this is a TIFF file. For example:

a004p008.tif	indicates the fourth call received and the eighth fax page
a002p001.tif	indicates the second call received and the first fax page
a004p004.tif	indicates the fourth call received and the fourth fax page

In multiple-channel systems, the first letter will be an "a" for channel 1, "b" for channel 2, and so on. Depending on the filename format, multiple pages can be received per call (Table 2). The default filename format can be set by the GFXRECVPATH command or through the queue record filename and operation fields. The operation field must be set to ANSWER_DEFAULT. For more information, see Chapter 4.

Table 2. Filename Formats for Receiving Multiple Pages

Filename Format	No. of Page/Call
f0001p01.tif	Up to 99
f001p001.tif	Up to 999
f01p0001.tif	Up to 9999

Receive Faxes in Multiple-Image TIFF Files

Multiple-page faxes may also be saved in one multi-page TIFF file. This option is turned on using the gfccontrol 36 command. For more information, refer to Chapter 3.

Multiple-Page Documents

The GDK channels automatically sends any filename and includes sequentially-numbered pages without them being explicitly specified. For example, to fax a three-page document named:

file001.tif
file002.tif
file003.tif

only the filename of the first page (file001.tif) should be specified for the filename to send.

If the filenames of all three pages are specified, the recipient will first receive these pages:

file001.tif
file002.tif
file003.tif

then:

file002.tif
file003.tif

and finally:

This is because GDK automatically looks for subsequently named files.

Controlling Next File Send Option

This feature lets you indicate whether to send the next file in the file sequence. When files are stored, each page associated with the file is saved using a numbering sequence (i.e., fax001.TIF, fax002.TIF, or data001.DAT, data002.DAT etc.).

You can specify whether or not to send the next file in the sequence by appending a command-line option to the end of the filename. This feature is enabled or disabled on a job-by-job basis.

Table 1 shows the next file send command options.

Table 1. Next File Send Options (Continued)

Binary File Transfer

GDK supports Binary File Transfer, which conforms to the T.434 BFT standard protocol. BFT reception can be enabled for T.434 BFT on a per-channel basis with the following command:

GFXFAXCONTROL 1020 1

or on a per-job basis by setting the queue record protocol field.

BFT transmission can be enabled per channel with the following command:

GFXFAXCONTROL 1021 2
  
or on a per-job basis by setting the queue record protocol field.

NOTE:

The GFXECM command must be set in order for BFT to work. If file transfer is used, the received filename will be a list of files in the format xxxxXFER.FLS. This list will contain the name of the file that was received, which will be the same as the original sent filename, as long as the DOS xxxxxxx.yyy format is observed, and the filename does not already exist on the target drive. The "f001p001" filenaming style is used if the sent filename already exists, but the original filename will be included in parentheses next to the filename that was written in the list. For example, A001XFER.FLS could contain:

c:\RECV\TEST.TXT
c:\RECV\A001P001.TIF (TEST.PCX)

Routing

Recent enhancements such as fax security and private mailboxes have created a need for a routing mechanism. Four types of routing mechanisms include: Dual-Tone Multi-Frequency (DTMF), Direct Inward Dialing (DID), T-1 digit collection, and a T.30 subaddress.

About the DTMF Capability

Most CP Fax Series boards have the ability to decode and store incoming touch-tone (DTMF) digits. With the ability to capture incoming DTMF digits, applications can be built to utilize this information for specialized tasks, such as sending out information in response to incoming calls.

For example, if an information service wanted to fax weather maps on request, it could assign DTMF digits to specific geographic areas. A client wanting a weather map of Northern California, for example, would be instructed to call a certain fax number and, at the tone, enter the assigned DTMF digits. GDK would receive the call and record the digits. The application would check the GDK records, load the transaction, and send the map to the caller's fax machine. Additionally, applications such as a network fax server can use this feature to provide security of information, because a workstation may be assigned specific digits. For example, only the intended recipient can view faxes sent to these digits; thus, access to incoming information can be controlled.

How GDK Works With DTMF

When a call is made to a CP Fax Series board that can detect DTMF tones, the board responds with a tone that is different from the fax tone, which signals the caller to enter the DTMF digits. After the DTMF digits are entered, the board responds with the fax tone, which signals the caller to activate the fax machine to send the fax. The CP Fax board receives the fax, and terminates the connection. If no tones are received, it waits for a designated time period and then continues with fax tone, assuming that a fax is on the other end.

After the connection is terminated, the fax board creates a queue record containing details of the transaction, including the DTMF digits. If the Dispatcher is running in batch processing mode, the queue record is then filed in a database called the Queue File. If the Dispatcher is running in interactive processing mode, the queue record is sent directly to the application. From there, an application takes over and uses the information stored in the queue record to carry out the next task.

To take advantage of the DTMF digits, callers must be instructed to use the appropriate digits at the DTMF tone. However, if a caller or an unattended fax machine transmits at the DTMF tone, GDK will accept the transmission and post the transaction without digits to a queue record. If this occurs, the fax must be routed manually.

Using the DTMF Capability

DTMF digit collection is a channel-specific feature. The following commands need to be set for each channel to enable the use of DTMF:

GFXDIGITS	Sets the number of DTMF tones that can be entered by a sender
GFXDTMFTIMEOUT	Sets the timeouts for waiting for DTMF input
GFXDTMFTONE	Specifies DTMF tone to issue when answering a call

Storing Routing Digits

When a fax is received, GDK stores the DTMF digits in the user_id field of the corresponding queue record in the Queue File. Then, an application can use this information for specialized tasks. A network fax server, for example, could use these digits to route incoming faxes.

The user_id field can contain a total of 34 characters. However, storage for only 24 characters is available, because other information, such as the user identification, may be stored in this field. (If no user identification is specified, "SYSOP" is used as the default.) GDK can handle up to 63 incoming digits; however, this will not be necessary in most cases. When it is necessary to store a large number of routing digits (such as a credit card number or a security code), this information will be stored on disk as a file. If the number of digits received is larger than the queue record can hold, a file will be created containing the digits followed by a null character. The decision to create a file is made on a call-by-call basis, because terminated input may not contain the quantity of digits specified by the GFXDIGITS command.

The name of the file that is created is appended to the user_id field as follows:

where "@" signifies that a filename is being given. The filename will be in the form:

where "F" is the channel number. The filename digits increment for each subsequent transaction.

Direct Inward Dialing (DID)

Direct Inward Dial (DID) capability is only available to CP Fax Series hardware with a DID interface. Refer to the CPD/220 hardware installation manual for further information on configuring your system for use with DID lines and about DID lines in general. The major advantage of routing using DID service is simplicity for the caller. The caller dials a single number and the central office (CO) extracts the routing digits from the inputted number, rather than have the caller input the digits at the DTMF tone after dialing the fax number. Enabling DTMF capability and the process of storing the routing digits are the same as described above, with the exception of no tone being needed to prompt the user. The GFXDTMFTONE command should not be used with DID setups.

T-1 Digit Collection

The CP Fax Series board is also capable of collecting digits automatically from the telephone company using a T-1 trunk. A CP4/SC, CP6/SC, or CP12/SC board is connected to a T-1 interface board via a PEB in a fax-only system (i.e., no voice boards on the PEB). The most common telephone interface board for this configuration is the Dianatel EA24. The commands to set up digit collection are the same as for the DID, including not using the GFXDTMFTONE command.

T.30 Subaddressing

T.30 subaddressing allows a string of characters and numbers to be sent with the fax. This string is known as the subaddress. It also allows fax servers to do routing based on this subaddress.

GDK supports T.30 subaddressing, but it is disabled by default. Add the following command to enable T.30 subaddressing for each channel requiring this routing capability:

GFXFAXCONTROL 71 1

Sending a Subaddress

The subaddress is appended to the end of the dialing string starting with a #.

NOTE:

The # is the default string delimiter. The start string delimiter can be configured using the GFXFAXCONTROL 73 command.

For example, to send a fax to 555-1212 with a subaddress of 9873, the appropriate dialing string should be: 555-1212#9873.

Receiving a Subaddress

The subaddress is stored in the USERID field of the queue record. To indicate that the USERID field contains a subaddress, the USERID field will start with S:=.

For example, if a fax was received with a subaddress of 9876, it would be represented in the USERID field as SYSOP;S:=9876.

Recording Line Noise

In the Answer-and-Receive mode, GDK can record the line noise and the status of telephone-line signals received during training. This information can then be used to determine the quality of a telephone line. If there is any fluctuation in the readings, be sure to receive a sufficient number of faxes to determine whether a problem is transitory or chronic.

Transparent PRI Support

Transparent PRI Support is an easy way to support the High-Density PRI solutions. This allows FSP developers to create ISDN PRI solutions to handle the PRI interfaces and the FAX resources without re-writing application code. The registry parameters that have been added to provide the Transparent PRI Support are defined in the New Parameters section in Chapter 3, Configuration Commands of this guide.

Click here to contact Dialogic Customer Engineering