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

Mon Dec 4 10:35:04 UTC 2017

Try with ecm false, and early_media false

Sent via mobile, please forgive typos and brevity.

cell: +39 347 266 56 18
Giovanni Maruzzelli
OpenTelecom.IT

On Dec 4, 2017 11:30 AM, "Kevin Olbrich" <ko at sv01.de> wrote:

> I just had a talk about this with our carrier and the problems seems on
> their side.
> This will not be fixed anytime soon, so they said it would be best, if we
> use T.38 inside and t38-to-g711 when connecting to them.
>
> I tried to set this in the incoming dialplan:
>
>
>>
>> <include>
>>   <extension name="public_did">
>>     <condition field="destination_number" expression="^\+(\d+)$|\d+$">
>>       <action application="set" data="domain_name=$${domain}"/>
>>       <action application="t38_gateway" data="peer"/>
>>       <action application="bridge" data="sofia/internal/${destina
>> tion_number}@192.168.31.11"/>
>>     </condition>
>>   </extension>
>> </include>
>>
>
>
> IP 192.168.31.11 is an asterisk machine, connecting the T.38 ATAs at
> various locations.
>
>
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.128433 [DEBUG]
>> switch_ivr_bridge.c:1614 (sofia/internal/%2B491122334455 at 192.168.31.11)
>> State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.128433 [DEBUG]
>> switch_core_state_machine.c:584 (sofia/internal/%2B49112233445
>> 5 at 192.168.31.11) Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 2)
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.128433 [DEBUG]
>> switch_core_state_machine.c:653 (sofia/internal/%2B49112233445
>> 5 at 192.168.31.11) State EXCHANGE_MEDIA
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.128433 [DEBUG]
>> mod_sofia.c:631 SOFIA EXCHANGE_MEDIA
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.148489 [DEBUG]
>> sofia.c:7084 Channel sofia/internal/%2B491122334455 at 192.168.31.11
>> entering state [received][100]
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.148489 [DEBUG]
>> sofia.c:7094 Remote SDP:
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 v=0
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 o=- 1512309774 1512309778 IN IP4
>> 192.168.31.11
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 s=Asterisk
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 c=IN IP4 192.168.31.11
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 t=0 0
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 m=image 4663 udptl t38
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxVersion:1
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38MaxBitRate:14400
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxTranscodingMMR
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxTranscodingJBIG
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxRateManagement:
>> transferredTCF
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxMaxDatagram:784
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxUdpEC:t38UDPRedundancy
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.148489 [DEBUG]
>> switch_core_media.c:4028 sofia/internal/%2B491122334455 at 192.168.31.11
>> T38 REFUSE on request
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.148489 [DEBUG]
>> sofia.c:8007 Reinvite resulted in codec negotiation failure.
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.168441 [DEBUG]
>> sofia.c:7077 Channel sofia/internal/%2B491122334455 at 192.168.31.11
>> skipping state [ready][488]
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.168441 [DEBUG]
>> sofia.c:7084 Channel sofia/internal/%2B491122334455 at 192.168.31.11
>> entering state [received][100]
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.168441 [DEBUG]
>> sofia.c:7094 Remote SDP:
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 v=0
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 o=- 1512309774 1512309779 IN IP4
>> 192.168.31.11
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 s=Asterisk
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 c=IN IP4 192.168.31.11
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 t=0 0
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 m=image 4663 udptl t38
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxVersion:1
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38MaxBitRate:14400
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxTranscodingMMR
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxTranscodingJBIG
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxRateManagement:
>> transferredTCF
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxMaxDatagram:784
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 a=T38FaxUdpEC:t38UDPRedundancy
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.168441 [DEBUG]
>> switch_core_media.c:4028 sofia/internal/%2B491122334455 at 192.168.31.11
>> T38 REFUSE on request
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.168441 [DEBUG]
>> sofia.c:8007 Reinvite resulted in codec negotiation failure.
>> ac858869-5320-48fb-b100-1a4a9c3d0851 2017-12-03 23:43:49.188433 [DEBUG]
>> switch_rtp.c:7271 Correct audio ip/port confirmed.
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.188433 [DEBUG]
>> sofia.c:7077 Channel sofia/internal/%2B491122334455 at 192.168.31.11
>> skipping state [ready][488]
>> ac858869-5320-48fb-b100-1a4a9c3d0851 2017-12-03 23:43:49.208437 [DEBUG]
>> sofia.c:7084 Channel sofia/external/anonymous at 87.234.1.183 entering
>> state [ready][200]
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:43:49.208437 [DEBUG]
>> switch_rtp.c:7271 Correct audio ip/port confirmed.
>> 7fb3d04b-31f4-4539-a13e-aeaea7a194e8 2017-12-03 23:44:33.188445 [NOTICE]
>> sofia.c:1012 Hangup sofia/internal/%2B491122334455 at 192.168.31.11
>> [CS_EXCHANGE_MEDIA] [NORMAL_CLEARING]
>>
>
>
> What I need is:
>
> FAX ATA (T.38) -> Asterisk (T.38) -> FreeSWITCH (T.38 to audio GW, refuse
> T.38 on A-leg) -> Carrier (audio)
>
> Carrier (audio) -> FreeSWITCH (audio to T.38, refuse T.38 on B-leg) ->
> Asterisk (T.38) -> FAX ATA (T.38)
>
> Asterisk is sending Re-INVITES as seen in the log above. Seems like I miss
> some settings in my dialplan?
>
> Kevin
>
> 2017-12-02 16:36 GMT+01:00 Kevin Olbrich <ko at sv01.de>:
>
>> I need to note that all components are SIP based, no other tech involved.
>>
>> Kevin
>>
>> 2017-12-02 13:41 GMT+01:00 Kevin Olbrich <ko at sv01.de>:
>>
>>> 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/go
>>>> faxip)
>>>>
>>>> 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_s
>>>>>> tring='PCMA,PCMU',fax_use_ecm=true,fax_enable_t38=true,fax_e
>>>>>> nable_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/free
>>>>> switch-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/free
>>>> switch-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/20171204/b4826b14/attachment-0001.html>