Freeswitch 1.6.19 and T.38 / INCOMPATIBLE_DESTINATION
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 ... Here is the log extract : recv 1391 bytes from udp/[10.9.30.152]:5060 at 23:47:39.443941: ------------------------------------------------------------------------ INVITE sip:0170993660@10.9.30.188:5060 SIP/2.0 Record-Route: <sip:10.9.30.152;lr=on> Record-Route: <sip:10.3.1.220;lr=on> Via: SIP/2.0/UDP 10.9.30.152;branch=z9hG4bK51d.d7e922c4.0 Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK51d.ba6f34d1.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac1339541470 Max-Forwards: 68 From: <sip:33183817938@gv-ics-prd-301>;tag=1c1339531455 To: <sip:0170993660@10.3.1.220;user=phone> Call-ID: 13395229682542018214736@10.3.1.231 CSeq: 1 INVITE Contact: <sip:33183817938@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:33183817938@10.3.1.220
;party=calling;privacy=off;screen=yes;screen-ind=3;npi=1;ton=1 Remote-Party-ID: <sip:0170993660@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: 417
v=0 o=AudiocodesGW 1339507326 1339507042 IN IP4 10.3.1.231 s=Phone-Call c=IN IP4 10.3.1.231 t=0 0 m=audio 23970 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 23972 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:33600 a=T38FaxMaxBuffer:3000 a=T38FaxMaxDatagram:560 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy ------------------------------------------------------------------------ send 477 bytes to udp/[10.9.30.152]:5060 at 23:47:39.444372: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.9.30.152;branch=z9hG4bK51d.d7e922c4.0 Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK51d.ba6f34d1.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac1339541470 Record-Route: <sip:10.9.30.152;lr=on> Record-Route: <sip:10.3.1.220;lr=on> From: <sip:33183817938@gv-ics-prd-301>;tag=1c1339531455 To: <sip:0170993660@10.3.1.220;user=phone> Call-ID: 13395229682542018214736@10.3.1.231 CSeq: 1 INVITE User-Agent: FreeSWITCH Content-Length: 0 ------------------------------------------------------------------------ ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [NOTICE] switch_channel.c:1104 New Channel sofia/internal_1/33183817938@gv-ics-prd-301 [ba17b1eb-961d-43fe-b820-cb469a8f292d] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_1/33183817938@gv-ics-prd-301) Running State Change CS_NEW (Cur 1 Tot 69) ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] sofia.c:9874 sofia/internal_1/33183817938@gv-ics-prd-301 receiving invite from 10.9.30.152:5060 version: 1.6.19 64bit ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] sofia.c:7085 Channel sofia/internal_1/33183817938@gv-ics-prd-301 entering state [received][100] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] sofia.c:7095 Remote SDP: ba17b1eb-961d-43fe-b820-cb469a8f292d v=0^M ba17b1eb-961d-43fe-b820-cb469a8f292d o=AudiocodesGW 1339507326 1339507042 IN IP4 10.3.1.231^M ba17b1eb-961d-43fe-b820-cb469a8f292d s=Phone-Call^M ba17b1eb-961d-43fe-b820-cb469a8f292d c=IN IP4 10.3.1.231^M ba17b1eb-961d-43fe-b820-cb469a8f292d t=0 0^M ba17b1eb-961d-43fe-b820-cb469a8f292d m=audio 23970 RTP/AVP 8 101^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=rtpmap:8 PCMA/8000^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=rtpmap:101 telephone-event/8000^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=fmtp:101 0-15^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=ptime:20^M ba17b1eb-961d-43fe-b820-cb469a8f292d m=image 23972 udptl t38^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxVersion:0^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38MaxBitRate:33600^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxMaxBuffer:3000^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxMaxDatagram:560^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxRateManagement:transferredTCF^M ba17b1eb-961d-43fe-b820-cb469a8f292d a=T38FaxUdpEC:t38UDPRedundancy^M ba17b1eb-961d-43fe-b820-cb469a8f292d ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4449 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4504 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4449 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMU:0:8000:20:64000:1] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4365 Set telephone-event payload to 101@8000 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:3061 Set Codec sofia/internal_1/33183817938@gv-ics-prd-301 PCMA/8000 20 ms 160 samples 64000 bits 1 channels ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_codec.c:111 sofia/internal_1/33183817938@gv-ics-prd-301 Original read codec set to PCMA:8 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4708 Set telephone-event payload to 101@8000 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_media.c:4767 sofia/internal_1/33183817938@gv-ics-prd-301 Set 2833 dtmf send payload to 101 recv payload to 101 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] ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:603 (sofia/internal_1/33183817938@gv-ics-prd-301) State NEW ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_1/33183817938@gv-ics-prd-301) Running State Change CS_HANGUP (Cur 1 Tot 69) ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:850 (sofia/internal_1/33183817938@gv-ics-prd-301) Callstate Change DOWN -> HANGUP ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:852 (sofia/internal_1/33183817938@gv-ics-prd-301) State HANGUP ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] mod_sofia.c:438 Channel sofia/internal_1/33183817938@gv-ics-prd-301 hanging up, cause: INCOMPATIBLE_DESTINATION ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] mod_sofia.c:577 Responding to INVITE with: 488 ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:60 sofia/internal_1/33183817938@gv-ics-prd-301 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:852 (sofia/internal_1/33183817938@gv-ics-prd-301) State HANGUP going to sleep ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:619 (sofia/internal_1/33183817938@gv-ics-prd-301) State Change CS_HANGUP -> CS_REPORTING ba17b1eb-961d-43fe-b820-cb469a8f292d 2018-04-25 23:47:39.434491 [DEBUG] switch_core_state_machine.c:584 (sofia/internal_1/33183817938@gv-ics-prd-301) Running State Change CS_REPORTING (Cur 1 Tot 69) send 784 bytes to udp/[10.9.30.152]:5060 at 23:47:39.446918: ------------------------------------------------------------------------ SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/UDP 10.9.30.152;branch=z9hG4bK51d.d7e922c4.0 Via: SIP/2.0/UDP 10.3.1.220;branch=z9hG4bK51d.ba6f34d1.0 Via: SIP/2.0/UDP 10.3.1.231;branch=z9hG4bKac1339541470 Max-Forwards: 68 From: <sip:33183817938@gv-ics-prd-301>;tag=1c1339531455 To: <sip:0170993660@10.3.1.220;user=phone>;tag=9USNQNQDByZ6a Call-ID: 13395229682542018214736@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: "0170993660" <sip:0170993660@10.3.1.220
;party=calling;privacy=off;screen=no
Thanks with anticipation D. Jeannerod
http://lists.freeswitch.org/pipermail/freeswitch-users/2017-January/124459.h... <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 ...
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.h...
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
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@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.h...
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
_________________________________________________________________________ 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
participants (3)
-
Dominique Jeannerod
-
Michael Jerris
-
Sergey Safarov