Rightfax10 SIP T.38

Recently I had some trouble with faxes using Rightfax 10 and T.38 over SIP after migrating from E1 ISDN to provider SIP trunks. The setup is as follows:

Service provider SIP Trunk CUBE CUCM Rightfax

The service provider offered us G.711 A-law, RFC 2833 as DTMF and T.38 as fax protocol (with fallback support for G.711 passthrough) on the SIP trunk. The Rightfax server was already in place and configured for T.38 using SIP directly with the old ISDN gateways. In the new setup we went for a more centrally managed dialplan and wanted the SIP trunk with Rightfax directly on CUCM. Rightfax was managed by a third party, but to say the least, they were not really helpful to us. I asked them to comply to the service provider requirements and they told me that wouldn’t be a problem. Eventually it appears all they did was change the IP adresses for the new routes and that’s about it.

To start off, I must admit that I had absolutely zero experience with Rightfax at first. After I got management access to Rightfax, I found that it was using the Dialogic Brooktrout SR140 as a virtual fax board. It has support for SIP, T.38 and G.711 A-law. RFC 2833 however is not supported.

First issue: with RFC 2833 not being supported incoming faxes didn’t get through due to the mismatch on CUCM between the CUBE SIP trunk and the Rightfax SIP trunk. This is not that uncommon and can be easily solved using an MTP. The only MTP supporting RFC 2833 and OOB conversions on T.38 though are the hardware MTPs. I had some DSPs left in CUBE, so I configured them as MTP and added them in a seperate MRGL for the Rightfax SIP trunk. This still doesn’t do the trick as an incoming call would try to dynamically insert an MTP at the first CUBE SIP trunk and not at the Rightfax SIP trunk. The CUBE SIP trunk has an MRGL with the default CUCM MTPs, I didn’t want to change this because there are other calls requiring the regular MTPs (contact center express for instance). Therefor I checked the MTP required checkbox at the Rightfax SIP trunk so that an incoming call would actually make use of the hardware MTPs at the Rightfax SIP trunk side to deal with the mismatch. Solved

Second issue: outgoing faxes were still causing problems. Apparantly rightfax advertises both G.711 A-law as µ-law. Initially I still believed that the third party had done everything they needed to do. Therefor I even experimented with transcoders. However after gaining management access on the Rightfax server, the real solution is to set the brooktrout configuration so that only A-law gets advertised. This can be done in Rightfax Enterprise Fax Manager. Stop the RightFax DocTransport service and right click it to open up the configuration.

 

Go to the settings of the SR140 and click on Configure Brooktrout.

 

Go to advanced mode

 

Go to SIP RTP paramenters and change the RTP codec list to “pcma” instead of “pcma pcmu”.

 

Third issue: some outgoing faxes went fine, some failed. Incoming faxes went fine all the time. It turned out that for certain outgoing faxes no T.38 switchover was initiated and therefor no T.38 was used and the fax failed. Why did some outgoing faxes work? Well for certain numbers the service provider was initiating the T.38 switchover, however for certain other numbers the service provider didn’t initiate it. Rightfax did not initiate any T.38 for outgoing faxes. I made the following changes to Rightfax.

First of all I enabled G.711 passthrough as fallback mechanism, since the service provider has passthrough as a fallback mechanism, Rightfax can be set to use this fallback as well.
Secondly I changed the Media Renegotiate Delay Outbound from -1, which means Rightfax does not initiate T.38 but waits for the other side to initiate it, to 2000 which means that Rightfax initiates T.38 switchover after 2s.

 

That’s about it. I only needed to save the configuration and press apply. Afterwards I started the DocTransport service again and from now on all faxes went fine.

For the sake of completeness my configuration of SIP trunks on CUCM and the dial-peer configuration on CUBE. The only thing to keep an eye on, besides the MTPs, is that Rightfax only supports UDP for SIP.

CUCM Rightfax Trunk configuration

 

 

CUCM Rightfax SIP Trunk Security Profile

 

 

CUCUM CUBE Trunk Configuration

 

CUCM CUBE SIP Trunk Security Profile

 

 

CUBE Dialpeer:

dial-peer voice 30001 voip
translation-profile outgoing SIPin
preference 1
destination-pattern [3-5]…
session protocol sipv2
session target ipv4:x.x.x.x
session transport udp
incoming called-number .
voice-class codec 200
dtmf-relay rtp-nte
fax-relay ecm disable
fax rate 14400
fax protocol t38 version 0 ls-redundancy 2 hs-redundancy 0 fallback pass-through g711alaw
no vad