T38 Integration

André Guimarães, 2012-06-14

Switzernet

T38 Integration.. 1

1.      Introduction.. 1

2.      Tests configuration.. 1

3.      Problems and possible solutions. 3

4.      Resources. 4

 

 

Introduction

The aim of this document is to describe how to integrate T38 with our current version of Astrad, report possible problems and solutions.

 

For sending fax there are two alternatives T30 and T38. T30 is the classical fax protocol where the fax is send encoded in the voice stream. T38 allows relaying faxes over IP.

 

The advantage of T38 over T30 in sending faxes over an IP network is that the T38 is more robust to delay and transmission errors. To send a fax in T30 over IP the sound must not be compressed (only G711 alaw or ulaw) and even so there is no guarantee of a successful transmission due to packet loss or bandwidth problems.

 

While it is possible to terminate a T30 fax and resend it as T38 it is not advisable as this would break the notification delivery system. The typical scenario would be conversion or encapsulation of the T30 signal in T38 in a T38 Fax Gateway.

 

Currently Asterisk support T38 Fax Gateway in version 10.

 

Tests configuration

 

The tests were done in the current version of Astrad which as Asterisk 1.8. So the tests only concern transmission in T38. The User agent used sends the fax in T38 and so there is no need to do gateway.

 

To test the following line was added to the IPS module configuration file in Asterisk, /etc/asterisk/sip.conf:

 

[general]

t38pt_udptl=yes,redundancy

 

According to voip-info.org most ATAs use redundancy and don’t support FEC or ignore it. So for the tests Redundancy was used as error correction. This is also supported by the operator used for the tests.

 

The tests were successful only with one User Agent: Zoiper. Other User agents were tested like Kapanga and FaxVoIP (links in references). Kapanga has a bug that cuts the SIP packet preventing it from sending in the SDP the T38 information and FaxVoIP never sent the reinvite with T38 information  neither sent the headers in the original INVITE.

 

Trace bellow of the call made by Zoiper between the Astrad and the provider. Full trace available but encoded by VPN [here – (keys)].

 

Due to the tests they were being made to test the provider, the 200 OK is received in duplicate.

 

 

The second INVITE (a re-invite) contains in the SDP:

 

v=0

o=root 647371141 647371142 IN IP4 91.121.122.64

s=Astrad013-1

c=IN IP4 91.121.122.64

t=0 0

m=image 4303 udptl t38

a=T38FaxVersion:0

a=T38MaxBitRate:14400

a=T38FaxRateManagement:transferredTCF

a=T38FaxMaxDatagram:397

a=T38FaxUdpEC:t38UDPRedundancy

 

which converts the call to T38, if accepted. In the answer to this INVITE, the provider sends:

 

v=0

o=PVG 1338812592650 1338812592650 IN IP4 212.249.199.9

s=-

p=+1 6135555555

c=IN IP4 212.249.199.9

t=0 0

m=image 58036 udptl t38

a=T38FaxVersion:0

a=T38FaxMaxBuffer:1100

a=T38FaxMaxDatagram:612

a=T38MaxBitRate:14400

a=T38FaxRateManagement:transferredTCF

a=T38FaxUdpEC:t38UDPRedundancy

 

Further tests need to be executed with more User Agents. Incoming faxes should also be tested. This will only be possible after the installation of the definitive connexion to this provider. At the moment it is in standby.

Problems and possible solutions

Is it possible to detect that traffic is fax and route it accordingly?

 

While Asterisk is capable of detecting fax, he can only do that after the call is answered and the fax is beginning to transmit. At hat point we’ve already route it to some vendor. This vendor might not support fax T38 and so we’ve no way to change provider without terminating the call (thus making the fax transmission fail). One possibility is to disconnect as soon we detect the call is fax and when the fax tries to retransmit we force the next call or calls to those numbers to go to a VoIP gateway.

 

How to redirect the Fax traffic to the T38 Provider:

 

Some possibilities:

-          Use a prefix to mark the traffic as fax.

-          Create a Rate that routes all numbers only to providers supporting T38.

-          Have a database with fax numbers destinations.

-          Disconnect all fax calls and when the fax tries to retransmit we route it to the T38 vendor.

-          Have accounts for fax sending and receiving only (calls from and to these accounts would be always considered as faxes)

 

Will it be possible to send T30 and convert it to T38 and vice-versa?

 

With the current version of Asterisk this is not advised. To do this we would need to receive the fax in each Astrad and then send it in T38 to the vendor. If we do the transmission like this, it would disrupt the transmission of notification and most faxes would be marked as well transmitted even if on the T38 side the transmission would fail. For this it will be better to use Asterisk 10. That version of Asterisk would also be able to convert faxes from T38 to T30 thus permitting to send through our other Vendors (transmission between Astrads and vendors in T38 and our vendor gateways would be responsible to do the conversion).

 

What will be needed for the fax transmission?

 

At first only T38 equipments should be able to send faxes. We can also develop an interface to allow people to send faxes: the customer would login, choose the file and number to send and we would be sent it from there. Another option could be to create an email account to receive the files for faxing. The customer sends the file to fax as an attachment and would write in the body of the email the authentication and number to fax. It is also possible to create a web service for faxing, where the customer would call a method we provide to send the fax, authenticate and tell us where to send it. In these three last cases we would know that the number is a fax machine and so we would use always the correct gateway. In my personal opinion I also think that this could be of interest to many enterprise customers and could get us more customers.

 

Conversion from T30 to T38 will never probably work correctly as in the connection between the customer and our nodes we would still have a reliability problem.

Resources

 

http://en.wikipedia.org/wiki/T.38

http://en.wikipedia.org/wiki/T.30

http://en.wikipedia.org/wiki/T.37

http://en.wikipedia.org/wiki/Internet_fax

http://www.voip-info.org/wiki/view/Asterisk+T.38

http://www.voip-info.org/wiki/view/Asterisk+T.38+Gateway

https://wiki.asterisk.org/wiki/display/AST/T.38+Gateway

 

http://www.zoiper.com/download_list.php

http://www.kapanga.net/IP/download.cfm

http://www.t38faxvoip.com/download.htm