[Freeswitch-users] Freeswitch 1.6.19 and T.38 / INCOMPATIBLE_DESTINATION

[Sergey Safarov]

Think you not applied recommendation

If you wish to retain the previous behavior you can set fax_enable_t38=true
in your vars.xml, You can also not set that and just set refuse_t38=true if
you wish to never do t.38.


пт, 27 апр. 2018 г. в 10:03, Dominique Jeannerod <
dominique.jeannerod at interact-iv.com>:

> Thanks a lot for this answer.
> I already read this information mail, and read the changes done for t38
> re-invite.
> The problem i have is NOT on the reinvite but directly on the first invite
> of the Call
> Do you think the behaviour also changed for the first invite ?
>
> Anyway, i will try the new configuration parameter, and test if it fixes
> my problem.
> My short term fallback plan would just be to downgrade to the 1.6.8
> version we already have on production.
>
>
> Le jeu. 26 avr. 2018 à 23:52, Michael Jerris <mike at jerris.com> a écrit :
>
>>
>> http://lists.freeswitch.org/pipermail/freeswitch-users/2017-January/124459.html
>>
>> On Apr 26, 2018, at 5:20 PM, Dominique Jeannerod <
>> dominique.jeannerod at interact-iv.com> wrote:
>>
>> Hello,
>>
>> I currently use Freeswitch 1.6.8-1 in production, and have some ISDN
>> gateways sending SDP including T.38 for voice calls (not faxes). Calls are
>> handled without problems by freeswitch.
>>
>> I have another platform, with freeswitch 1.6.19 and same configuration.
>> However, voice calls received with SDP including t.38 are rejected with
>> 488 INCOMPATIBLE_DESTINATION :
>> ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG]
>> switch_core_media.c:4028 sofia/internal_1/33183817938 at gv-ics-prd-301 T38
>> REFUSE on request
>> ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [NOTICE]
>> sofia.c:7566 Hangup sofia/internal_1/33183817938 at gv-ics-prd-301 [CS_NEW]
>> [INCOMPATIBLE_DESTINATION]
>>
>> I didn't find any valid configuration to make those calls accepted,
>> except configuring proxy_media, which I don't want to use.
>>
>> Is this behaviour a "normal" behaviour ? Could it be a bug ?
>> This is a very big issue for us ...
>>
>>
>> _________________________________________________________________________
>> 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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20180427/49c76282/attachment.html>