[Freeswitch-users] T.38 gateway and peer/self
Peter Steinbach
lists at telefaks.de
Mon Feb 27 15:40:39 MSK 2017
Hello Michael,
I just updated a test machine with current Freeswitch from GIT. He I did
not find any T.38 reinvite issue.
Best regards
Peter
On 02/24/17 22:06, Michael Jerris wrote:
> If you have to switch to older free switch, that is a problem, we need
> to figure out exactly what is going on with current freeswitch or the
> issue will just never get fixed.
>
> Please lets look at what happens when its running on latest 1.6
> release not older release and figure out how to get that working properly.
>
>
>> On Feb 24, 2017, at 3:46 PM, Peter Steinbach <lists at telefaks.de
>> <mailto:lists at telefaks.de>> wrote:
>>
>> 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/
>>> <http://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://www.freeswitch.org/>
>>>>> http://confluence.freeswitch.org
>>>>> <http://confluence.freeswitch.org/>
>>>>> http://www.cluecon.com <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 <http://www.freeswitch.org/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> */Brian West/*
>>>>> brian at freeswitch.org <mailto:brian at freeswitch.org>
>>>>>
>>>>> */Twitter: @FreeSWITCH , @briankwest/*
>>>>>
>>>>> http://www.freeswitchbook.com <http://www.freeswitchbook.com/>
>>>>> http://www.freeswitchcookbook.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 <http://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 <http://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 <http://telefaks.de>
>> Internet: www.telefaks.de
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org <mailto: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
>
>
>
> _________________________________________________________________________
> 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/20170227/354a6292/attachment-0001.html
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list