t38_gateway hangs up non-deterministic with normal clearing
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@20i,PCMU@20i,G729'}sofia/internal/accountcode@10.23.101.10^+${dialed_extension}@10.23.101.10"></action> ... </condition> </extension> </context> tested freeswitch versions: FreeSWITCH Version 1.6.20-37-987c9b9~64bit (-37-987c9b9 64bit) FreeSWITCH Version 1.10.1-release-12-f9990221e6~64bit (-release-12-f9990221e6 64bit) -> version where logfile is created this is the debug section where the call gets hung up: 287b2821-05a1-4ff6-9449-dac913b803eb 2019-12-03 20:32:23.257123 [DEBUG] switch_core_media.c:5285 sofia/internal/46wp809758@10.23.101.10 T38 IS POSSIBLE on request cc222460-f51e-453e-9a09-c2e97e6b8af9 2019-12-03 20:32:23.259118 [ALERT] switch_rtp.c:1595 sofia/external/+4318033811@193.32.51.146:5060 audio stat 100.00 673/673 flaws: 0 mos: 4.50 v: 0.00 0.00/0.00 cc222460-f51e-453e-9a09-c2e97e6b8af9 2019-12-03 20:32:23.259118 [DEBUG] switch_ivr_bridge.c:824 sofia/internal/46wp809758@10.23.101.10 ending bridge by request from write function cc222460-f51e-453e-9a09-c2e97e6b8af9 2019-12-03 20:32:23.259118 [DEBUG] switch_ivr_bridge.c:916 BRIDGE THREAD DONE [sofia/external/+4318033811@193.32.51.146:5060] 287b2821-05a1-4ff6-9449-dac913b803eb 2019-12-03 20:32:23.260120 [ALERT] switch_ivr_bridge.c:1893 sofia/internal/46wp809758@10.23.101.10 receive message [UNBRIDGE] full logfile of call is enclosed fsctl debug settings: fsctl loglevel debug fsctl debug_level 9
On Tue, Dec 3, 2019 at 11:19 PM Roman Dissauer <roman@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@20i ,PCMU@20i,G729'}sofia/internal/accountcode@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
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@gmail.com>:
On Tue, Dec 3, 2019 at 11:19 PM Roman Dissauer <roman@dissauer.net <mailto:roman@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@20i,PCMU@20i,G729'}sofia/internal/accountcode@10.23.101.10 <mailto:accountcode@10.23.101.10>^+${dialed_extension}@10.23.101.10 <mailto:dialed_extension%7D@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 <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 <https://signalwire.community/>
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com <https://freeswitch.com/>
Official FreeSWITCH Sites https://freeswitch.com/oss <https://freeswitch.com/oss> https://freeswitch.org/confluence <https://freeswitch.org/confluence> https://cluecon.com <https://cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> https://freeswitch.com <https://freeswitch.com/>
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@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@gmail.com>:
On Tue, Dec 3, 2019 at 11:19 PM Roman Dissauer <roman@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@20i ,PCMU@20i,G729'}sofia/internal/accountcode@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@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@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@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@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
we know that fax over g711 is not the best solution but most of our upstream carriers do not support t.38 but in fact we have approx. 0.7 to 2ms delay over fiber to the upstream crriers TDM switches. We’ve done a lot of testing and we’ve done statistics over several thousand fax attempts with multi page faxes and the result is pretty good at about 95% success rate within the first attempt. Another fact is that if i send a fax through our system as described below and the customer side is another FreeSWITCH it works perfectly! We tested with several t.38 capable pots adapters and it is not really deterministic if the problem exists. First we thought that it only exists if we have several hundred calls on the switch but the issue exists also if there are only 1-3 calls on the switch. Sometimes it works but mostly FreeSWITCH drops the call during the re-Invite. When this issue occurs the call comes via interconnect (A-leg), customer equipment (B-leg) is answering the call. Call is established with g.711a and after about 6 seconds FAX is detected by the end user equipment and an re-Invite is sent back to routing FreeSWITCH. This answers with trying, busy here, bye on the B-leg and also hangs up A-leg with a bye. Screenshot enclosed. I can also pm you the full sip trace of the call. Thanks, Roman
Am 06.12.2019 um 07:56 schrieb Giovanni Maruzzelli <gmaruzz@gmail.com>:
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@dissauer.net <mailto:roman@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@gmail.com <mailto:gmaruzz@gmail.com>>:
On Tue, Dec 3, 2019 at 11:19 PM Roman Dissauer <roman@dissauer.net <mailto:roman@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@20i,PCMU@20i,G729'}sofia/internal/accountcode@10.23.101.10 <mailto:accountcode@10.23.101.10>^+${dialed_extension}@10.23.101.10 <mailto:dialed_extension%7D@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 <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 <https://signalwire.community/>
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com <https://freeswitch.com/>
Official FreeSWITCH Sites https://freeswitch.com/oss <https://freeswitch.com/oss> https://freeswitch.org/confluence <https://freeswitch.org/confluence> https://cluecon.com <https://cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> https://freeswitch.com <https://freeswitch.com/>
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com <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 <https://signalwire.community/>
Professional FreeSWITCH Services sales@freeswitch.com <mailto:sales@freeswitch.com> https://freeswitch.com <https://freeswitch.com/>
Official FreeSWITCH Sites https://freeswitch.com/oss <https://freeswitch.com/oss> https://freeswitch.org/confluence <https://freeswitch.org/confluence> https://cluecon.com <https://cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> https://freeswitch.com <https://freeswitch.com/>
-- Sincerely,
Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18
_________________________________________________________________________
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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
participants (2)
-
Giovanni Maruzzelli
-
Roman Dissauer