[Freeswitch-users] T.38 gateway and peer/self
Peter Steinbach
lists at telefaks.de
Fri Feb 24 23:46:15 MSK 2017
I finally found a solution, for those who are interested.
* I switched back to old Freeswitch from Feb 2016, as new FS always
answered with 488 on T.38 reinvite from the B-Leg
* Then I implemented the following (coding outside of FS with XML-Curl)
o When call is done with T.38 on boths legs, do not anything
special, just use a minimum dialplan
o if B-leg does not answer with T.38, this normally fails in my
environment. I then store a Value NOT38 to the dialled number
for 1/2 hour in a cache
+ when then the fax machine is retrying the same call, I
lookup the cache and return another dialplan with T38
gateway (self) enabled
That way, pure T.38 calls work nicely, and calls with T.39 on the B-leg
work on the second try.
Hope this helps. At last here in Germany, we have to find some
workarounds, as fax implementation on some carrier's side (to say the
positive) does not improve.
Best regards
Peter
On 02/24/17 14:29, Peter Steinbach wrote:
> Hello Brian,
>
> I just updated to latest GIT. Dialplan ist still
>
> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action
> set(fax_enable_t38=true)
> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action
> set(fax_enable_t38_request=true)
> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action
> set(execute_on_answer=t38_gateway self)
> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action ring_ready()
> Dialplan: sofia/internalvpn2/492927aaaaaa at 10.7.0.1 Action
> bridge(sofia/gateway/sip.provider.com/4940bbbbbbbbbbbbbbb at sip.provider.com)
>
>
> However the behavour changed now
> 2017-02-24 13:50:18.913016 [NOTICE] switch_ivr_originate.c:3633
> Channel [sofia/internalvpn2/492927aaaaaa at 10.7.0.1] has been answered
> 2017-02-24 13:50:18.913016 [DEBUG] sofia.c:7241 Channel
> sofia/internalvpn2/492927aaaaaa at 10.7.0.1 entering state [completed][200]
> *EXECUTE sofia/internalvpn2/492927aaaaaa at 10.7.0.1 t38_gateway(peer)*
> 2017-02-24 13:50:18.913016 [DEBUG] switch_core_media_bug.c:841
> Attaching BUG to sofia/internalvpn2/492927aaaaaa at 10.7.0.1
> 2017-02-24 13:50:18.913016 [DEBUG] switch_channel.c:3780
> (sofia/internalvpn2/492927aaaaaa at 10.7.0.1) Callstate Change RINGING ->
> ACTIVE
> 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_originate.c:3691
> Originate Resulted in Success:
> [sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com]
> 2017-02-24 13:50:18.913016 [DEBUG] switch_ivr_bridge.c:1696
> (sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com) State Change
> CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA
> 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:584
> (sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com) Running State
> Change CS_EXCHANGE_MEDIA (Cur 2 Tot 10)
> 2017-02-24 13:50:18.913016 [DEBUG] switch_core_state_machine.c:653
> (sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com) State EXCHANGE_MEDIA
> 2017-02-24 13:50:18.913016 [DEBUG] mod_sofia.c:645 SOFIA EXCHANGE_MEDIA
> 2017-02-24 13:50:18.953025 [DEBUG] sofia.c:7241 Channel
> sofia/internalvpn2/492927aaaaaa at 10.7.0.1 entering state [ready][200]
> 2017-02-24 13:50:18.953025 [DEBUG] switch_rtp.c:7021 Correct audio
> ip/port confirmed.
> 2017-02-24 13:50:19.333126 [DEBUG] switch_rtp.c:7021 Correct audio
> ip/port confirmed.
> 2017-02-24 13:50:19.333126 [DEBUG] switch_core_io.c:448 Setting BUG
> Codec PCMA:8
> 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7241 Channel
> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com entering state
> [received][100]
> 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:7251 Remote SDP:
> v=0
> o=HuaweiSoftX3000 1487923856 1487923858 IN IP4 185.39.xx.yy
> s=HuaweiSoftX3000
> c=IN IP4 185.39.xx.yy
> t=0 0
> m=image 16762 udptl t38
> a=T38FaxVersion:0
> a=T38MaxBitRate:14400
> a=T38FaxRateManagement:transferredTCF
> a=T38FaxMaxBuffer:500
> a=T38FaxMaxDatagram:500
> a=T38FaxUdpEC:t38UDPRedundancy
>
> *2017-02-24 13:50:26.013047 [DEBUG] switch_core_media.c:4634
> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com T38 REFUSE on request*
> 2017-02-24 13:50:26.013047 [DEBUG] sofia.c:8152 Reinvite resulted in
> codec negotiation failure.
> *2017-02-24 13:50:26.033201 [DEBUG] sofia.c:7234 Channel
> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com skipping state
> [ready][488]*
> *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2212 Fax Tone
> Detected. [peer][]*
> *2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2080
> sofia/internalvpn2/492927aaaaaa at 10.7.0.1 starting gateway mode to
> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com*
> 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2098
> (sofia/internalvpn2/492927aaaaaa at 10.7.0.1) State Change CS_EXECUTE ->
> CS_RESET
> 2017-02-24 13:50:31.993164 [DEBUG] mod_spandsp_fax.c:2101
> (sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com) State Change
> CS_EXCHANGE_MEDIA -> CS_RESET
> 2017-02-24 13:50:31.993164 [DEBUG] switch_core_media_bug.c:1208
> Removing BUG from sofia/internalvpn2/492927aaaaaa at 10.7.0.1
> 2017-02-24 13:50:31.993164 [DEBUG] switch_ivr_bridge.c:792
> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com ending bridge by
> request from write function
>
> In this case the sip provider comes back with T.38 reinvite and
> Freeswitch refuses it.
>
> As you mentioned that there are further settings and variables (I see
> e.g. "fax_t38_tx_reinvite_packet_count" in the release notes), I am
> wondering how I will neeed to set this up in order to have in one
> single dialplan:
>
> * send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP
> Provider and pass it to a-leg
> * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite
> from SIP Provider and then do T.38 Gateway in FS.
>
>
> Best regards Peter
>
>
> On 02/24/17 08:52, Peter Steinbach wrote:
>> Hello Brian,
>>
>> this Version of Freeswitch is from 09-Feb-2016. So I think, we should
>> update.
>>
>> We need to cover 2 scenarios
>>
>> * send fax to SIP Provider(b leg) and have T.38 Re-invite from SIP
>> Provider and pass it to a-leg
>> * send fax to SIP Provider(b leg), do NOT receive T.38 Re-invite
>> from SIP Provider and then do T.38 Gateway in FS.
>>
>> And no: We cannot foresee, whether the SIp provider will do T.38 and
>> not. Here in Germany, the main incumbant PSTN provider did not
>> implement T.38, so it depends on the target number and actual route,
>> if this will be T.38 or not. A call to a certain number can be T.38
>> today and tomorrow it will be T.30 only, as some peering partner
>> changed the routes in the meantime.
>>
>> Best regards
>> Peter
>>
>>
>> On 02/23/17 20:38, Brian West wrote:
>>> What revision of FreeSWITCH are you on? These behaviors have been
>>> solidified in 1.6.15, Sadly MOST of the details of how it all works
>>> is locked up in my head, I've just not had the time to write it all
>>> down and update the documentation. Can you outline all the
>>> scenarios you need to cover and if you have the ability know ahead
>>> of time which one needs to apply?
>>>
>>> /b
>>>
>>>
>>> On Thu, Feb 23, 2017 at 8:23 AM, Peter Steinbach <lists at telefaks.de
>>> <mailto:lists at telefaks.de>> wrote:
>>>
>>> Hello,
>>>
>>> we have the following screnario
>>>
>>> * The caller, a local fax machine (Fax, ATA and Freeswitch)
>>> with T.38, is behind a slow line so therefore T.38 is needed
>>> here
>>> * a central Freeswitch fax server serves as a central gateway
>>> to the SIP provider
>>> * the SIP provider sometimes reinvites T.38 and sometimes not.
>>> * In case, the SIP provider does NOT answer with T.38, the
>>> central Freeswitch fax server shall act as a T.38 gateway
>>> and transcode between local fax (T.38) and SIP provider (T.30)
>>> * In case, the SIP provider does answer with T.38, the central
>>> Freeswitch fax server shall pass T.38 to the local fax
>>> ,machine (T.38)
>>>
>>> How we set this up
>>>
>>> * according to the wiki we have a dialplan as follows: (this
>>> is what CLI shows)
>>>
>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1
>>> <mailto:sofia/internalvpn2/49274xxxxx at 10.7.0.1> Action
>>> set(fax_enable_t38=true)
>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1
>>> <mailto:sofia/internalvpn2/49274xxxxx at 10.7.0.1> Action
>>> set(fax_enable_t38_request=true)
>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1
>>> <mailto:sofia/internalvpn2/49274xxxxx at 10.7.0.1> Action
>>> set(execute_on_answer=t38_gateway self)
>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1
>>> <mailto:sofia/internalvpn2/49274xxxxx at 10.7.0.1> Action ring_ready()
>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1
>>> <mailto:sofia/internalvpn2/49274xxxxx at 10.7.0.1> Action
>>> bridge(sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx at sip.provider.com
>>> <mailto:sofia/gateway/sip.provider.com/xxxxxxxxxxxxxxx at sip.provider.com>)
>>>
>>> In all profiles, we have
>>> <param name="t38-passthru" value="true"/>
>>>
>>> In case, the SIP provider does NOT answer with T.38, it works.
>>> The caller's side is reinvited with T.38, the SIP provider side
>>> is T.30
>>>
>>> What the problem is: When the SIP provider' side IS answering
>>> with T.38, then (sometimes, when I send it via cli from the
>>> local freeswitch near the sending fax machine, it works)
>>>
>>> * caller initiates a call
>>> * call is bridged to the SIP provider' side
>>> * we receive a T.38 Reinvite from the SIP provider' side
>>> * Freeswitch sends Trying back to the the SIP provider' side
>>> * Freeswitch logs: set(execute_on_answer=t38_gateway self)
>>> * Freeswitch sends a T.38 Reinvite to the caller, establishes
>>> T.38 on this side.
>>> * But the T.38 Reinvite from the SIP provider' side is not
>>> answerered
>>> * So the SIP provider' sidehangs up after 10 sec of timeout.
>>>
>>> What are we doing wrong here? Is it possible to act as a t.38
>>> passthrough router and a T.38 gateway in the same dialplan?
>>>
>>>
>>>
>>> --
>>> With kind regards
>>> Peter Steinbach
>>>
>>> Telefaks Services GmbH
>>> mailto:lists (att) telefaks.de <http://telefaks.de>
>>> Internet: www.telefaks.de <http://www.telefaks.de>
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
>>> http://www.freeswitchsolutions.com
>>> <http://www.freeswitchsolutions.com>
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org <http://confluence.freeswitch.org>
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> <mailto:FreeSWITCH-users at 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>
>>> http://www.freeswitch.org
>>>
>>>
>>>
>>>
>>> --
>>>
>>> */Brian West/*
>>> brian at freeswitch.org <mailto:brian at freeswitch.org>
>>>
>>> */Twitter: @FreeSWITCH , @briankwest/*
>>>
>>> http://www.freeswitchbook.com
>>> http://www.freeswitchcookbook.com
>>>
>>> Allison prompts for FreeSWITCH:
>>>
>>> *https://www.gofundme.com/allison-prompts-for-freeswitch*
>>>
>>> Wish to schedule a meeting?
>>>
>>> http://app.timebridge.com/#/meet/freeswitch
>>>
>>> Got Bugs? Report them here <https://freeswitch.org/jira>! |
>>> Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
>>>
>>> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
>>> *Skype:*briankwest
>>>
>>>
>>>
>>> _________________________________________________________________________
>>> 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
>>
>>
>> --
>> With kind regards
>> Peter Steinbach
>>
>> Telefaks Services GmbH
>> mailto:lists (att) telefaks.de
>> Internet: www.telefaks.de
>>
>>
>>
>> _________________________________________________________________________
>> 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
>
>
> --
> With kind regards
> Peter Steinbach
>
> Telefaks Services GmbH
> mailto:lists (att) telefaks.de
> Internet: www.telefaks.de
>
>
>
> _________________________________________________________________________
> 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
--
With kind regards
Peter Steinbach
Telefaks Services GmbH
mailto:lists (att) telefaks.de
Internet: www.telefaks.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170224/276f70e2/attachment-0001.html
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list