[Freeswitch-users] T.38 parameters causing call rejections

[Tristan Dean]

Hi All

 

I am having trouble on a new FreeSWITCH-based SBC we've built. We are going
through some SBCs and upgrading them. In this case, we are upgrading an old
SBC running: 1.4.15 64bit built from source.

 

The new version is running on Debian 8.3 (AMD64) Stable with the packaged
version of FreeSWITCH:  1.6.14 -23-e460bf8 64bit

We are tying this in with a hardware swap, so the 1.6.14-23 box is new.

 

We have a few instances where our upstream carrier presents us with a SDP
which contains:

m=image 56594 udptl t38

a=T38FaxUdpEC:t38UDPRedundancy

a=T38FaxRateManagement:transferredTCF

 

Historically (version 1.4.15) these seem to be ignored and FreeSWITCH passes
the call out obeying the absolute_codec_string set during bridge.
Transcoding is allowed and when negotiating a codec with the carrier, these
parameters were ignored and G.711a was usually negotiated on both legs.

 

On the new platform, FreeSWITCH seems to be attempting to parse these and
negotiate T.38. I am certain that it is something silly that I'm doing
wrong, but can't find it and would welcome others' thoughts. What have I
missed? Has anyone seen this before? I have tried t38_passthru=true to no
avail.

 

I can't set proxy_media=true or bypass_media=true as we need FreeSWITCH to
shield other devices from the SDP parameters above.

Most of the configuration is stored in a database and returned to FreeSWITCH
using mod_xml_curl. I have pasted some configuration excerpts, SIP messages
and logs in: https://pastebin.freeswitch.org/view/de059ffc

 

Please let me know if there is any other information you need from me.

 

Many thanks in advance for your assistance.

 

Tristan



---
This email has been checked for viruses by AVG.
http://www.avg.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170116/66287ac8/attachment.html