Issues with T.38 on outgoing fax (sofia T38 invite failed)
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_number='+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:transferredTCF 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
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@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_
number='+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: transferredTCF 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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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_ 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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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/${ destination_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@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/% 2B491122334455@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/% 2B491122334455@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Giovanni Maruzzelli
-
Kevin Olbrich
-
Raúl Alexis Betancor Santana