Administrator Guide: T.38 Support

Introduction

The Communication Server offers 2 levels of T.38 support:
  • T.38 passthrough mode
  • T.38 gateway mode

T.38 passthrough support

T.38 passthrough mode is established when 2 endpoints understand sending and receiving T.38 UDP traffic, with the Communication Server module inbetween, just passing through all the T.38 traffic from one side to the other. The setup of this is simple (it is done completely in the resources), but requires 2 endpoints that support T.38 traffic.

T.38 gateway support

T.38 gateway mode is established when 1 endpoint understands T.38 traffic, but the other endpoint does not. The Communication Server module actually translates the T.38 traffic to a normal voice codec and the other way around. This mode requires configuration of the resources, and a specific action in the callflows.

Supported installations

Escaux has tested and validated the following installation setups (in both directions):

  • Sangoma Netborder (G711) <-- Communication Server 2 --> Cisco ATA (T.38) (Gateway mode)
  • Sangoma Netborder (G711) <-- Communication Server 2 --> Fax Server (G711) (Non-T.38)
  • Cisco ATA (T.38) <-- Communication Server 2 --> Fax Server (G711) (Gateway mode)
  • Cisco ATA (T.38) <-- Communication Server 2 --> Non-T.38 enabled SIP trunk (G711) (Gateway mode)
  • Cisco ATA (T.38) <-- Communication Server 2 --> T.38 enabled SIP trunk (T.38) (Passthrough mode)
  • Fax Server (G711) <-- Communication Server 2 --> T.38 enabled SIP trunk (T.38) (Gateway mode)

  • Sangoma Netborder (G711) <-- Communication Server 3 --> Cisco ATA (T.38) (Gateway mode)
  • Sangoma Netborder (G711) <-- Communication Server 3 --> Fax Server (G711) (Non-T.38)
  • Cisco ATA (T.38) <-- Communication Server 3 --> Fax Server (G711) (Gateway mode)
  • Cisco ATA (T.38) <-- Communication Server 3 --> Non-T.38 enabled SIP trunk (G711) (Gateway mode)
  • Cisco ATA (T.38) <-- Communication Server 3 --> T.38 enabled SIP trunk (T.38) (Passthrough mode)
  • Fax Server (G711) <-- Communication Server 3 --> T.38 enabled SIP trunk (T.38) (Gateway mode)

ALERT! At all times the fax device should be configured on the SOP that is connected to the PSTN. If you have a cluster of SOP's, this means you have to configure the fax server or the ATA device on the gateway SOP. ALERT!

ALERT! Other setups might also work, but are currently not supported ALERT!

ALERT! T.38 support for SIP trunks depends on a validation by Escaux. Please contact Escaux to know if your SIP trunk provider is supported ALERT!

Requirements

To correctly use T.38 features of the Communication Server module, we recommend using at least these versions of related modules and resources:

Modules

  • Communication Server 2.3.4 or 3.3.4
  • Cisco ATA Support 1.5.3
  • Sangoma Card Support 2.4.0 (if you use any telephony interface cards)

Resources

  • Cisco SPA112 1.15.0 ( recommended)
  • Cisco SPA2102 1.15.0
  • Cisco SPA8000 1.8.0 ( recommended)
  • Cisco SPA3102 1.5.0
  • SangomaBRI 2.3.0
  • SangomaPRI 2.3.0

Actions

  • STARTFAXAPPLICATION3.11

The supported installations have been validated with components included in the template Fusion 3.3.0.

FAX device settings

  • Put fax transmission rate ( speed) to 9600 baud. If your fax doesn't support this speed, we recommend to change you fax device for an HP OfficeJet 4630.
    • The available fax speed settings on the HP OfficeJet 4630 are:
      • Fast v.34 (33600 bps)
      • Medium v.17 (14400 bps)
      • Slow v.29 (9600 bps)
    • To set the fax speed:
      1. From the Home screen on the printer display, press the Up and Down buttons to select Fax, and then press OK.
      2. Select Settings, and then select Advanced Settings.
      3. Select Fax Speed.
      4. Select an option, and then press OK.

Configuration

ATA Configuration

To enable T.38 on your ATA, you need to set the following settings :
  • Network_Jitter Level: extremely high
  • Jitter Buffer Adjustment : no
  • Call Waiting Serv: no
  • Three Way Conf Serv: no
  • Preferred Codec : G711a
  • Use Pref Codec Only : yes
  • Disable any feature like echo cancellation or silence suppression
  • T38 : yes
  • Fax passthru codec: G711a

ATA Physical connection

The ATA's only support one simultaneous T.38 session per module. The SPA2102 and SPA112 contain one module. This means that you can only have 1 T.38 session per SPA2102/SPA112. For the SPA8000, there are 4 modules for 8 port pairs (1-2, 3-4, 5-6, 7-8), This means that on each of these pairs you can only have 1 T.38 session at the same time.

Sangoma Netborder configuration

Netborder requires special configuration. We need to enable T.38 on the module, but keep T.38 disabled on the resources. We have to enable it on the module because on a low level, it enables some fax detection features that trigger specific latency settings for fax calls:
  • Sangoma Card Support (>= 2.4.0): Enable T.38 : yes
  • SangomaBRI (>= 2.1.0): Enable T.38 : no
  • SangomaPRI (>= 2.0.0): Enable T.38 : no

Fax server configuration

For incoming faxes to the fax server, just make sure that STARTFAXAPPLICATION >= 3.11 is used in the callflow for the extension. It will always enable gateway mode if it is possible.

For outgoing faxes from the fax server, you need to make sure that T.38 Gateway mode is achieved by using the steps described in T.38 Gateway mode

T.38 Passthrough mode

To configure T.38 passthrough mode, simply configuring the resources with T.38 support is sufficient. As an example, we have a setup with a SIP trunk and an ATA (Cisco SPA112) that both support T.38. To the ATA we have connected a normal analog fax machine on the FXS port. All it takes really is to configure in both the SIP Trunk and CiscoSPA112 resources the T.38 parameters to "yes".

  • SIP Trunk configuration:
    t38-trunk.png
  • CiscoSPA112 configuration:
    t38-ata.png

Expected behaviour in a call

In the example call we expect the following to happen:
  1. When the call is set up normal preferred codec traffic is established (G711a or G711u). Since the Communication Server module is not configured in T.38 gateway mode it will not manipulate this traffic and just keep forwarding voice traffic.
  2. One of the endpoints (or both) is supposed to detect the fax tone and sends a SIP INVITE to the Communication Server to request a T.38 session.
  3. The Communication Server responds a SIP OK to this request and the T.38 session is set up.
  4. You should now see only T.38 udptl packets sent between the Communication Server and both endpoints.

  • Here's an example of a T.38 passthrough session:
    t38-passthrough.png

T.38 Gateway mode

First complete the configuration part of T.38 passthrough mode. To achieve gateway mode, all you have to do is use a SetVar action to set the dialplan function "FAXOPT(gateway)" to yes. e.g. FAXOPT(gateway)=yes. This needs to be done for every call where one of the channels does not support T.38 mode. Typically, this happens when using the fax server or a SIP trunk that has no support for T.38.

  • SetVar in the callflow:
    t38-setvar.png

Note that this also has to be done when you want to send a fax with an ATA. If the ATA supports T.38 and the PSTN gateway does not, you need to use an outgoing callflow for the ATA. To accomplish this, you need to take these configuration steps:
  • Create a restriction group call RestrictFax
  • Create a route group FaxOut
  • Make sure the new restriction group includes the new routegroup
  • Create a new callflow (e.g. *001) that does a SetVar of the same FAXOPT(gateway)=yes variable, and then executes a Redirect action to the ${NumberToDial} extension. Optionally you can also set the context to redirect to to DefaultOut
  • In the routes (Extra cluster routing for a cluster), create a new route _X. with route group FaxOut and execute the MapNumber v1.16+ action.
    • Manipulate number: strip all digits
    • Add prefix: *001 (make sure you use the appropriate number here. It might not be *001 for your setup)
    • Variable: NumberToDial
    • Restriction Group: default
  • Put all the ATA resources in the RestrictFax restriction group.

Expected behaviour in a call

In the example call we expect the following to happen:
  1. When the call is set up, normal preferred codec traffic is established (G711a or G711u). Because of the FAXOPT(gateway)=yes, the Communication Server is now in gateway mode.
  2. When the Communication Server is in gateway mode it actively listens for fax tones. As soon as it detects these tones, it will send a SIP INVITE to the endpoint that supports T.38 traffic.
  3. The endpoint responds to this request with a SIP OK message and the Communication Server starts translating the fax voice traffic into T.38 udptl packets.
  4. In this session you will see T.38 udptl packets on one side and G711a/G711u RTP packets on the other side of the Communication Server.

  • Here's an example of a T.38 gateway session:
    t38gw.png

Debugging

TEST FAX

You can use the following document as a test Fax T38_TEST_PAGES.pdf: TESTFAX

Debug fax connection

You can see on the console whether the T.38 gateway was started: 
00000064*CLI> fax show sessions

Current FAX Sessions:

Channel              Tech       FAXID      Type  Operation  State           File(s)                       
SIP/SDSD0001-0000001 Spandsp    5          T.38  gateway    Active                                        

1 FAX sessions

To view detailed information about the session: 
00000064*CLI> fax show session 5

FAX Session Details:
--------------------

session                : 5
operation              : Gateway
state                  : Active
ECM Mode               : Yes
Data Rate              : 9600
Page Number            : 1

You can also see on the console if there are any UDPTL packets being sent or received: 
00000064*CLI> udptl set debug on
UDPTL Debugging Enabled
[Jan 25 15:45:56]  UDPTL (SIP/SDSD0001-0000001b): packet to 172.16.35.11:16444 (seq 134, len 16)
[Jan 25 15:45:57]  UDPTL (SIP/SDSD0001-0000001b): packet to 172.16.35.11:16444 (seq 135, len 19)
[Jan 25 15:45:57]  UDPTL (SIP/SDSD0001-0000001b): packet to 172.16.35.11:16444 (seq 136, len 22)
[Jan 25 15:45:57]  UDPTL (SIP/SDSD0001-0000001b): packet to 172.16.35.11:16444 (seq 137, len 27)
[Jan 25 15:45:57]  UDPTL (SIP/SDSD0001-0000001b): packet to 172.16.35.11:16444 (seq 138, len 29)
[Jan 25 15:45:57]  UDPTL (SIP/SDSD0001-0000001b): packet to 172.16.35.11:16444 (seq 139, len 26)
[Jan 25 15:45:57]  UDPTL (SIP/SDSD0001-0000001b): packet to 172.16.35.11:16444 (seq 140, len 21)
[Jan 25 15:45:58]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 711, len 10)
[Jan 25 15:46:00]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 712, len 60)
[Jan 25 15:46:00]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 713, len 112)
[Jan 25 15:46:00]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 714, len 112)
[Jan 25 15:46:00]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 715, len 112)
[Jan 25 15:46:00]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 716, len 112)
[Jan 25 15:46:00]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 717, len 85)
[Jan 25 15:46:00]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 718, len 85)
[Jan 25 15:46:00]  UDPTL (SIP/SDSD0001-0000001b): packet from 172.16.35.11:16444 (seq 719, len 112)
Keep in mind that UDPTL sessions don't contain constant streams of packets like traditional RTP streams.

External documentation

Copyright © Escaux SA