So, I tested with " <X-PRE-PROCESS cmd="set" data="fax_enable_t38=true"/>" in vars.xml, which i didn't do previously. The behaviour is quite different. However, the call is directly rejected after the first INVITE (which is not a REINVITE), but instead of having " T38 REFUSE on request", i have : 2018-04-27 09:28:48.697285 [DEBUG] switch_core_media.c:4041 sofia/internal_2/698778763@gv-ics-prd-301 T38 ACCEPT on request 2018-04-27 09:28:48.697285 [DEBUG] switch_core_media.c:4146 sofia/internal_2/698778763@gv-ics-prd-301 T38 IS NOT POSSIBLE on request 2018-04-27 09:28:48.697285 [NOTICE] sofia.c:7566 Hangup sofia/internal_2/698778763@gv-ics-prd-301 [CS_NEW] [INCOMPATIBLE_DESTINATION] Is there another parameter to configure to allow T38 ? Add a codec (I only have PCMA, and PCMU) Full log : INVITE sip:0170993650@10.9.30.34:5060 SIP/2.0 Record-Route: <sip:10.3.1.220;lr=on> Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK002b.b2b0e9d2.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac408981189 Max-Forwards: 69 From: <sip:698778763@gv-ics-prd-301>;tag=1c408970979 To: <sip:0170993650@10.3.1.220;user=phone> Call-ID: 408970087274201872848@10.3.1.231 CSeq: 1 INVITE Contact: <sip:698778763@10.3.1.231:5060> Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Remote-Party-ID: <sip:698778763@10.3.1.220
;party=calling;privacy=off;screen=yes;screen-ind=3;npi=1;ton=2 Remote-Party-ID: <sip:0170993650@10.3.1.220>;party=called;npi=1;ton=2 User-Agent: Audiocodes-Sip-Gateway-Mediant 3000/v.6.00A.056 Content-Type: application/sdp Content-Length: 413
v=0 o=AudiocodesGW 408954776 408954489 IN IP4 10.3.1.231 s=Phone-Call c=IN IP4 10.3.1.231 t=0 0 m=audio 7850 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv m=image 7852 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:33600 a=T38FaxMaxBuffer:3000 a=T38FaxMaxDatagram:560 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy ------------------------------------------------------------------------ send 374 bytes to udp/[10.3.1.220]:5060 at 09:28:49.974884: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK002b.b2b0e9d2.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac408981189 Record-Route: <sip:10.3.1.220;lr=on> From: <sip:698778763@gv-ics-prd-301>;tag=1c408970979 To: <sip:0170993650@10.3.1.220;user=phone> Call-ID: 408970087274201872848@10.3.1.231 CSeq: 1 INVITE User-Agent: FreeSWITCH Content-Length: 0 ------------------------------------------------------------------------ 2018-04-27 09:28:49.957287 [NOTICE] switch_channel.c:1104 New Channel sofia/internal_2/698778763@gv-ics-prd-301 [233f8391-10e6-4877-a792-6ad2a0f651e0] 2018-04-27 09:28:49.957287 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_2/698778763@gv-ics-prd-301) Running State Change CS_NEW (Cur 1 Tot 2) 2018-04-27 09:28:49.957287 [DEBUG] sofia.c:9874 sofia/internal_2/698778763@gv-ics-prd-301 receiving invite from 10.3.1.220:5060 version: 1.6.19 64bit 2018-04-27 09:28:49.957287 [DEBUG] sofia.c:7085 Channel sofia/internal_2/698778763@gv-ics-prd-301 entering state [received][100] 2018-04-27 09:28:49.957287 [DEBUG] sofia.c:7095 Remote SDP: v=0 o=AudiocodesGW 408954776 408954489 IN IP4 10.3.1.231 s=Phone-Call c=IN IP4 10.3.1.231 t=0 0 m=audio 7850 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 m=image 7852 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:33600 a=T38FaxMaxBuffer:3000 a=T38FaxMaxDatagram:560 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4449 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4504 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4449 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMU:0:8000:20:64000:1] 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4365 Set telephone-event payload to 101@8000 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:3061 Set Codec sofia/internal_2/698778763@gv-ics-prd-301 PCMA/8000 20 ms 160 samples 64000 bits 1 channels 2018-04-27 09:28:49.957287 [DEBUG] switch_core_codec.c:111 sofia/internal_2/698778763@gv-ics-prd-301 Original read codec set to PCMA:8 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4708 Set telephone-event payload to 101@8000 2018-04-27 09:28:49.957287 [DEBUG] switch_core_media.c:4767 sofia/internal_2/698778763@gv-ics-prd-301 Set 2833 dtmf send payload to 101 recv payload to 101 2018-04-27 09:28:49.977279 [DEBUG] switch_core_media.c:4041 sofia/internal_2/698778763@gv-ics-prd-301 T38 ACCEPT on request 2018-04-27 09:28:49.977279 [DEBUG] switch_core_media.c:4146 sofia/internal_2/698778763@gv-ics-prd-301 T38 IS NOT POSSIBLE on request 2018-04-27 09:28:49.977279 [NOTICE] sofia.c:7566 Hangup sofia/internal_2/698778763@gv-ics-prd-301 [CS_NEW] [INCOMPATIBLE_DESTINATION] 2018-04-27 09:28:49.977279 [DEBUG] switch_core_state_machine.c:603 (sofia/internal_2/698778763@gv-ics-prd-301) State NEW 2018-04-27 09:28:49.977279 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_2/698778763@gv-ics-prd-301) Running State Change CS_HANGUP (Cur 1 Tot 2) 2018-04-27 09:28:49.977279 [DEBUG] switch_core_state_machine.c:850 (sofia/internal_2/698778763@gv-ics-prd-301) Callstate Change DOWN -> HANGUP 2018-04-27 09:28:49.977279 [DEBUG] switch_core_state_machine.c:852 (sofia/internal_2/698778763@gv-ics-prd-301) State HANGUP 2018-04-27 09:28:49.977279 [DEBUG] mod_sofia.c:438 Channel sofia/internal_2/698778763@gv-ics-prd-301 hanging up, cause: INCOMPATIBLE_DESTINATION 2018-04-27 09:28:49.977279 [DEBUG] mod_sofia.c:577 Responding to INVITE with: 488 send 720 bytes to udp/[10.3.1.220]:5060 at 09:28:49.978310: ------------------------------------------------------------------------ SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK002b.b2b0e9d2.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac408981189 Max-Forwards: 69 From: <sip:698778763@gv-ics-prd-301>;tag=1c408970979 To: <sip:0170993650@10.3.1.220;user=phone>;tag=vy16j7B2HN1Xm Call-ID: 408970087274201872848@10.3.1.231 CSeq: 1 INVITE User-Agent: FreeSWITCH Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION" Content-Length: 0 Remote-Party-ID: "0170993650" <sip:0170993650@10.3.1.220
;party=calling;privacy=off;screen=no
2018-04-27 8:24 GMT+02:00 Dominique Jeannerod < dominique.jeannerod@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org