[Freeswitch-users] Issues with T.38 on outgoing fax (sofia T38 invite failed)

Sat Dec 2 12:41:54 UTC 2017

Hi,

thanks for the link but I was unable to find information on how to
configure my installation of FreeSwitch 1.6 to make things work.

I think I need to explain a little bit more on what I am planning to do:
FreeSwitch will be used as a SBC to the carrier. It's firewall is limited
to the carriers network on the first interface.
The second interface is a local subnet where an Asterisk 13 server (PBX) is
located, connecting the phones and ATAs (last with T.38 support).
For asterisk it is only necessary so set (FAXOPT(gateway)=yes) to have it
detect CNG on audio and query both legs for T.38 (or receive a request in
advance).
It then decides if it goes to passthru mode or transcode.

As far as I understand the FreeSwitch docs, there are these options
(located in dialplan default before bridge):

> <action application="set" data="fax_enable_t38=true"/> <!-- Enable t.38
> for this call -->
> <action application="set" data="fax_enable_t38_request=true"/> <!-- Enable
> t38_gateway to send a t.38 reinvite when a fax tone is detected. If using
> t38_gateway peer then you need to export this variable instead of set -->
> <action application="set" data="execute_on_answer=t38_gateway self"/>
> <!--Execute t38_gateway on answer. self or peer. self: send a reinvite back
> to the a-leg. peer reinvite forward to the b-leg -->

<action application="export" data="fax_enable_t38=true"/> <!-- Required as
> of v1.6 -->
> <action application="export" data="t38_passthru=true"/>

*What I would like to accomplish is getting as much as T.38 I can get.* The
ATA should always be able to negotiate T.38 with Asterisk (which seems to
work atm), FreeSwitch should then negotiate T.38 if Asterisk or the carrier
asks for it (no CNG detection).
I am not sure if I can just enable t38_gateway and passthru, this case is
not listed on confluence or the old wiki. Even if I do, it does not work.

FreeSwitch might need to transcode T.38 to audio for our backup carrier who
does not support T.38.

Kind regards,
Kevin

2017-12-02 9:20 GMT+01:00 Raúl Alexis Betancor Santana <rbetancor at gmail.com>
:

> Some carriers gateways doesn't like a T.38 invite on advance, usually the
> order that gives better results for faxing are first invite on PCMU/PCMA
> (or any other supported codec) and then re-invite to T.38.
>
> Take a look at how gonicus gofaxip do-it (https://github.com/gonicus/
> gofaxip)
>
> On Fri, Dec 1, 2017 at 10:21 PM, Kevin Olbrich <ko at sv01.de> wrote:
>
>> Hi!
>>
>> Our carrier supports T.38 for outgoing faxes. I am trying to send faxes
>> like this:
>>
>> originate {origination_caller_id_name='kevin',origination_caller_id_nu
>>> mber='+49123456789',ignore_early_media=true,absolute_codec_
>>> string='PCMA,PCMU',fax_use_ecm=true,fax_enable_t38=true,
>>> fax_enable_t38_request=true}sofia/gateway/carrier_1/+4912121212
>>> &txfax(/opt/faxout.tif)
>>
>>
>>
>> Log:
>>
>> 668fd128-f2f5-4af5-9536-6780762c2efa 2017-12-01 21:38:57.513164 [DEBUG]
>>> sofia_glue.c:1295 sofia/external/+4912121212 sending invite version: 1.6.19
>>> -36-7a77e0b 64bit
>>> 668fd128-f2f5-4af5-9536-6780762c2efa Local SDP:
>>> 668fd128-f2f5-4af5-9536-6780762c2efa v=0
>>> 668fd128-f2f5-4af5-9536-6780762c2efa o=FreeSWITCH 1512130268 1512130270
>>> IN IP4 123.123.123.123
>>> 668fd128-f2f5-4af5-9536-6780762c2efa s=FreeSWITCH
>>> 668fd128-f2f5-4af5-9536-6780762c2efa c=IN IP4 123.123.123.123
>>> 668fd128-f2f5-4af5-9536-6780762c2efa t=0 0
>>> 668fd128-f2f5-4af5-9536-6780762c2efa m=image 30466 udptl t38
>>> 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxVersion:0
>>> 668fd128-f2f5-4af5-9536-6780762c2efa a=T38MaxBitRate:14400
>>> 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxFillBitRemoval
>>> 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxRateManagement:transfe
>>> rredTCF
>>> 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxMaxBuffer:2000
>>> 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxMaxDatagram:400
>>> 668fd128-f2f5-4af5-9536-6780762c2efa a=T38FaxUdpEC:t38UDPRedundancy
>>> 668fd128-f2f5-4af5-9536-6780762c2efa
>>> 668fd128-f2f5-4af5-9536-6780762c2efa 2017-12-01 21:38:57.533158 [DEBUG]
>>> sofia.c:7084 Channel sofia/external/+4912121212 entering state [calling][0]
>>> 668fd128-f2f5-4af5-9536-6780762c2efa 2017-12-01 21:38:57.673120 [DEBUG]
>>> sofia.c:6294 sofia/external/+4912121212 T38 invite failed
>>> 668fd128-f2f5-4af5-9536-6780762c2efa 2017-12-01 21:38:57.673120 [DEBUG]
>>> sofia.c:7077 Channel sofia/external/+4912121212 skipping state [ready][488]
>>
>>
>>
>> Carrier confirmed that T.38 is possible... What could be the cause for
>> this? How can I enforce T.38 instead of falling back to g711a (hangup on
>> failed invite)?
>>
>> Thanks.
>>
>> Kind regards,
>> Kevin
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20171202/5d2c590d/attachment.html>