T38UDP endpoint filter

Provide entry and exit points for duplex T.38 fax data carried in UDP packets. For more information about T38UDP endpoint filter endpoint filter parameters, refer to T38UDP endpoint filter endpoint address structure and T38UDP endpoint filter endpoint parameter structure.

Note: T38UDP endpoints do not currently support IPv6.

Filter ID

MSP_ENDPOINT_T38FDX

Initialization structure

T38UDP_ENDPOINT_PARMS

Restrictions

Used in T.38 fax full duplex connections.

Channel connections

Connect to T.38 fax full duplex channels.

Commands

T38UDP endpoints respond to the following commands:

With the exception of the MSP_CMD_T38UDP_CONFIG command (see above), T38UDP endpoints can receive filter commands any time after they are created.

When sending MSP_CMD_T38UDP_CONFIG commands, applications provide a pointer to an msp_ENDPOINT_T38UDP_CONFIG structure. This structure contains all the parameters used to configure the T38UDP endpoint when the application
created it.

When using the MSP_CMD_T38UDP_CONFIG command, applications can specify a value of 0xFFFF for 16-bit parameters or 0xFFFFFFFF for 32-bit parameters (or -1 in decimal format) to retain the existing settings for any endpoint parameters. Otherwise, the endpoint expects a new value for every parameter in the structure. For more information about T38UDP endpoint parameters, refer to the Overview of endpoint structures or to the mspinit.h header file.

For a list of command IDs and their associated structures, refer to the mspcmd.h header file.

Queries

T38UDP full duplex endpoint filters respond to the following query any time after the endpoint is created:

Sending an MSP_QRY_T38UDP_STATUS query returns the following structure:

typedef struct tag_msp_ENDPOINT_T38UDP_STATUS {
//T38 UDP Data
     DWORD      FilterId;
     DWORD      ipFilterState;
     IPADDRESS  localIPAddr;
     DWORD      localPort;
     IPADDRESS  remoteIPAddr;
     DWORD      remotePort;
//T38 UDP Stats
     DWORD      rxDrop;
     DWORD      rxPkts;
     DWORD      rxBytes;
     DWORD      txDrop;
     DWORD      txFail;
     DWORD      txPkts;
     DWORD      txBytes;
//T38 IFP Encoder Data 
     DWORD      v21_bytes_per_ifp_packet;
     DWORD      page_modem_ifp_duration;
     DWORD      t30_indicator_send_count;
     DWORD      t30_indicator_send_period;
//T38 UDPTL Encoder Data
     DWORD      error_protection_scheme;
     DWORD      redundant_ifp_packets;
     DWORD      ifp_pkts_per_fec_message;
     DWORD      fec_messages_per_udptl_pkt;
     DWORD      num_duplicate_indicator_udptl_packets;
     DWORD      num_duplicate_v21_udptl_packets;
     DWORD      num_duplicate_page_modem_udptl_packets;
//T38 IFP Decoder Data
     DWORD      queue_size;
     DWORD      buffering_time;
     DWORD      page_data_keep_alive_time;
//T38 UDPTL Decoder Data
     DWORD      enable_error_recovery;
} msp_ENDPOINT_T38UDP_STATUS;

Note: FEC is not supported.

The msp_ENDPOINT_T38UDP_STATUS query structure provides the following information:

Unsolicited event

When enabled, T38UDP endpoints return the following unsolicited event:

For information about using T38UPD endpoint unsolicited events to implement voice/T.38 fax switchover, refer to the Dialogic® NaturalAccess™Fusion VoIP API Developer's Manual.

Receiving T38 packets from the IP network

When the T38UDP endpoint receives T.38 packets from the packet network interface, it decodes them into primary IFP packets and, if applicable, error recovery information. This process is called T.38 UDPTL decoding. When enabled, T38UDP endpoints generate a MSPEVN_T38_PACKET_DETECTED event the first time that they receive a valid UDPTL packet. This event signals the application to switch over from voice to fax data transmission. When T.38 fax endpoints are disabled and re-enabled, they once again detect the arrival of the first fax packet and return an MSPEVN_T38_PACKET_DETECTED event.

The T38UDP endpoint's IFP decoder receives asynchronous input (IFP packets) from the endpoints UDPTL decoder. The T38UDP endpoint converts data from an asynchronous flow to a synchronous flow before it transfers the data to a T.38 fax full duplex channel. The endpoint reorders the IFP packets during the queuing process and, depending on the error recovery scheme used and the network conditions, lost IFP packets can be recovered from subsequent UDPTL packets.

To prevent underflows in the IFP decoding queue resulting from network jitter, the MSPP service uses a buffering mechanism (controlled by the buffering_time parameter) to pre-fill the queue prior to sending data to the T.38 full duplex channel. This buffering mechanism is similar to the jitter mechanism used by the MSPP voice channel jitter filter.

During unfavorable network conditions, the T38UDP endpoint's efficiency in recovering and reordering IFP packets increases as the number of packets kept in the IFP decoder reorder queue increases. Applications can increase the number of IFP packets in the queue by using the MSP_CMD_T38IFPDEC_CONFIG filter command to increase the value of the buffering_time parameter.

Note: Fax sessions are relatively immune to the delay introduced by IFP decoder buffering mechanism (unlike voice connections where users notice degraded performance when the delay exceeds 200 ms). However, the timing requirements of the T.30 protocol make it nearly impossible to maintain a fax transmission when the one-way delay (roughly, the sum of network delay + buffering time) exceeds 1500 ms.

The actual size of the IFP decoder reorder queue (specified by the queue_size parameter) must be set in accordance with the buffering time. The longer the buffering time, the larger the number of IFP packets that need to be stored in the reorder queue. The queue size should also be large enough to prevent (or limit) the number of overflows during network bursts.

If the IFP decoder queue runs empty during the course of a page transmission (for example, due to bad network conditions), that application can keep the modem signal alive by setting (either through the endpoint's initialization parameters, or through the MSP_CMD_T38IFPDEC_CONFIG filter command) an appropriate page_data_keep_alive_time parameter value. Setting this parameter to a non-zero value specifies that the T.38 fax IFP decoder filter keeps the modem signal alive for a specified (in ms.) duration. This parameter can be particularly useful for networks that frequently experience congestion. This feature only works for non-ECM fax sessions.

Receiving fax data from MSPP T.38 Full Duplex channels

In T.38 fax sessions, fax data and session progress indicators are conveyed through IFP packets. Gateways indicate when they detect signals such as CED, HDLC preamble flags, and modem modulation training by sending T30 indicators. T.38 fax emitting gateways send T30 indicators to receiving gateways and vice versa.

When a T38UDP endpoint receives demodulated data from a T.38 fax full duplex channel, the endpoint analyzes the data and assembles the appropriate IFP packet components depending on the nature of the signal (whether it contains session progress indicators or fax data).

Note: Since V.21 is a low bit rate modem, Dialogic recommends setting the v21_bytes_per_ifp_packet parameter to a low value. For example, a single IFP packet that contains two V.21 bytes, provides a packet period of approximately 2 x 26.6 = 53.3 ms. with the minimum amount of HDLC bit stuffing (2 x 32 = 64 ms. with the maximum amount of HDLC bit stuffing).

For all other modulations (ECM or non-ECM), the size of the page modem data IFP is determined by the page_modem_frames_per_ifp_packet parameter value.

Any parameters that the application sets for the IFP encoder process (either during endpoint initialization or through the MSP_CMD_T38IFPENC_CONFIG endpoint command) will effect the rate at which the T.38 fax gateway sends IFP packets over the IP network.

Before sending T.38 data to the IP network, the T38UDP endpoint encodes T.38 UDPTL packets by adding a primary IFP packet, and optionally adding any error recovery information.

The application specifies the type of T.38 error recovery information the T.38 fax UDPTL encoder filter adds to each T.38 packet by either specifying an appropriate error_protection_scheme parameter the endpoint's initialization parameters, or sending an MSP_CMD_T38UDPTLENC_CONFIG filter command.

To make a T.38 system more tolerant to packet loss, applications can use the UDP packet duplication (this feature is outside the scope of the ITU-T T.38 specification) in conjunction with a T.38 error recovery scheme. However, packet duplication can reduce the throughput of the system by increasing the packet processing load.

UDP packet duplication can be set individually for the following types of primary T.38 IFP packets:

• V21 IFP packets

• Page modem IFP packets

• Indicators

The following illustration shows a T38UDP endpoint:

See also

T.38 fax relay channel filter, Jitter channel filter, Voice decoder channel filter, Voice encoder channel filter