[Freeswitch-users] t38_gateway hangs up non-deterministic with normal clearing

[Giovanni Maruzzelli]

Just a couple thoughts :

- fax over G711 VoIP is totally unreliable, hit or miss, random. It's a
fact of nature, no matter how good your internet lines are
- maybe you want try to answer the incoming, wait for 1 second so RTP flow
is well established, and then bridge

-giovanni



On Fri, Dec 6, 2019 at 1:57 AM Roman Dissauer <roman at dissauer.net> wrote:

> this is our topology:
>
> customer pbx <-> kamailio + rtpengine <-> several FreeSWITCH Machines <->
> kamailio <-> several interconnection carriers
>
> what we have to address for inbound/outbound calls:
> inbound call comes from any interconnection carrier which mostly does NOT
> have t.38 faxing what is no issue because we have reliable internet lines
> to our carriers. Our customers want to have t.38 faxing because of
> reliability of faxing over standard internet lines. So we have to transcode
> g.711a codec to t.38 in freeswitch. Same is true for outbound calls where
> customer pbxes send t.38 re-Invite but the upstream interconnection carrier
> does not accept t.38.
>
> sometimes faxing is fine with this mechanism but mostly the fax is
> rejected by a „NORMAL CLEARING“ as soon as the re-Invite is coming in.
> FreeSWITCH is sending BYE to both call legs.
>
> what we intend to do with our dialplan on an example - incoming calls
>
> 1. call is coming in via external profile with g.711a Codec
> 2. set refuse_t38=true sets t38 to be rejected coming from a-leg -
> external carrier
> 3. export fax_enable_t38=true will enable t38 both call legs
> 4. export nolocal:sip_execute_on_image=t38_image=t38_gateway self nocng
> will enable t38 only on b-leg - customer side
> 5. call is being bridged to kamailio where it gets routed to the customer
>
> thank you!
>
> best regards,
> Roman
>
> Am 04.12.2019 um 14:02 schrieb Giovanni Maruzzelli <gmaruzz at gmail.com>:
>
> On Tue, Dec 3, 2019 at 11:19 PM Roman Dissauer <roman at dissauer.net> wrote:
>
>> we have an issue with t38_gateway where calls which should be transcoded
>> from PCMA to t38 get hangup non-deterministic. It doesn’t matter if there
>> is only one call or if there are hundrets of calls on the freeswitch.
>> Sometimes it happens that we get several faxes transcoded but then we again
>> have several faxes which don’t go through. problem exists (tested) on
>> FreeSWITCH 1.6 and FreeSWITCH 1.10.
>>
>> this is the dialplan section where t38_gateway is set up for b-leg on an
>> inbound call:
>>
>> <context name="hosted_numbers">
>>          <extension name="43732601458-DDI" continue="true">
>>             <condition field="${outside_call}" expression="^true$"
>> break="never"/>
>>             <condition field="${dialed_extension}"
>> expression="^(43732601458)(\d{0,4})$“>
>>                ...
>>                <action application="set" data="refuse_t38=true"></action>
>>                <action application="export"
>> data="fax_enable_t38=true"></action>
>>                <action application="export"
>> data="nolocal:sip_execute_on_image=t38_gateway self nocng"></action>
>>                <action application="bridge"
>> data="{sip_cid_type=pid,sip_contact_user=accountcode,absolute_codec_string='PCMA at 20i
>> ,PCMU at 20i,G729'}sofia/internal/accountcode at 10.23.101.10^+${
>> dialed_extension}@10.23.101.10"></action>
>>                ...
>>             </condition>
>>          </extension>
>>       </context>
>>
>>
>
> Would you detail, line by line, what is the intended purpose of each line
> of dialplan?
>
> Also, your topology, and the intended result
>
> -giovanni
>
> _________________________________________________________________________
>
> The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
> services.
> Build your next product on our scalable cloud platform.
>
> Join our online community to chat in real time
> https://signalwire.community
>
> Professional FreeSWITCH Services
> sales at freeswitch.com
> https://freeswitch.com
>
> Official FreeSWITCH Sites
> https://freeswitch.com/oss
> https://freeswitch.org/confluence
> https://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
> https://freeswitch.com
>
>
> _________________________________________________________________________
>
> The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
> Enhance your FreeSWITCH install with disruptive priced SMS and PSTN
> services.
> Build your next product on our scalable cloud platform.
>
> Join our online community to chat in real time
> https://signalwire.community
>
> Professional FreeSWITCH Services
> sales at freeswitch.com
> https://freeswitch.com
>
> Official FreeSWITCH Sites
> https://freeswitch.com/oss
> https://freeswitch.org/confluence
> https://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
> https://freeswitch.com



-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20191206/e559a286/attachment.html>