[Freeswitch-users] T.38 gateway and peer/self

Brian West brian at freeswitch.org
Mon Feb 27 18:18:37 MSK 2017


Also there was a small logic bug in 1.6.14 that was fixed in FS-9943
6ff51458e25c2759e2e4d39965174604007a0cc7

We would 488 the reinvite, and switch to udptl mode anyway.  Thats fixed in
1.6.15.  Or worked around in 1.6.14 by setting fax_enable_t38=true in
vars.xml

/b


On Mon, Feb 27, 2017 at 9:15 AM, Brian West <brian at freeswitch.org> wrote:

> I need to point out that there was a slight behavior change in fax
> handling in 1.6.14+, It was related to 488 handling, We do not now by
> default accept a t.38 re-invite, You must set fax_enable_t38=true, or we
> will 488 the re-invite, and some devices do not handle this well.  You can
> restore the previous default behavior by setting fax_enable_t38=true in
> vars.xml
>
> I had sent this out, the is the second time a behavior change notice has
> gone out and very few have seen it.
>
> /b
>
>
> On Mon, Feb 27, 2017 at 6:40 AM, Peter Steinbach <lists at telefaks.de>
> wrote:
>
>> 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> 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)
>>       - When call is done with T.38 on boths legs, do not anything
>>       special, just use a minimum dialplan
>>       - 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 si
>> p.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
>> <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
>> <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
>> <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
>> <sofia/internalvpn2/492927aaaaaa at 10.7.0.1> starting gateway mode to
>> sofia/external/4940bbbbbbbbbbbbbbb at sip.provider.com
>> <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>
>> 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 Action
>>> set(fax_enable_t38=true)
>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1 Action
>>> set(fax_enable_t38_request=true)
>>> Dialplan: 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 Action ring_ready()
>>> Dialplan: sofia/internalvpn2/49274xxxxx at 10.7.0.1 Action bridge(
>>> 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 GmbHmailto:lists <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
>>>
>>
>>
>>
>> --
>>
>> *Brian West*
>> 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*
>> <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 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002>
>> | *M:*+1918424WEST (9378)
>> *Skype:*briankwest
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>>
>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>
>>
>>
>> --
>> With kind regards
>> Peter Steinbach
>>
>> Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de
>> Internet: www.telefaks.de
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>>
>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>
>>
>>
>> --
>> With kind regards
>> Peter Steinbach
>>
>> Telefaks Services GmbHmailto:lists <lists> (att) telefaks.de
>> Internet: www.telefaks.de
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>>
>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>
>>
>>
>> --
>> With kind regards
>> Peter Steinbach
>>
>> Telefaks Services GmbHmailto:lists <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
>>
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services: consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.com
>>
>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>
>>
>>
>> --
>> With kind regards
>> Peter Steinbach
>>
>> Telefaks Services GmbHmailto:lists <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
>>
>
>
>
> --
>
> *Brian West*
> 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*
> <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 <(918)%20420-9001> | *F:*+19184209002 <(918)%20420-9002>
> | *M:*+1918424WEST (9378)
> *Skype:*briankwest
>



-- 

*Brian West*
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*
<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170227/7b3bdc62/attachment-0001.html 


Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users mailing list