- FreeSWITCH-users - FreeSWITCH Mailing Lists

3CX-Sip-Trunk / Freeswitch cannot reach 3CX
by Thorsten Göllner 08 Jan '19

08 Jan '19

Hi, has anybody experience with 3CX-SIP-Trunks? I have installed Freeswitch and added an extension (trunk-1). On 3CX-Side I added a SIP-Trunk (generic sip provider) and I can see a succesfull registration. Now I make a call to Freeswitch and want to pass it to 3CX-Sip-Trunk. But when bridging to user/trunk-1 I get a "Originate Resulted in Error Cause: 41 [NORMAL_TEMPORARY_FAILURE]" error (with no delay). 3CX is installed as a VM in a Azure-Cloud behind NAT. I disabled local iptables and the Firewall-Test on 3CX is all fine. Freeswitch is on bare metal with a public ip. When making a call, wireshark on 3CX-machine shows the INVITE followed by "Destination unreachable (Port unreachable)". But I am not sure, if this is a firewall-issue or something else. Any idea? Thanks in advance, Thorsten

3 3

WSS certs
by Nathan Stratton 08 Jan '19

08 Jan '19

I created my wss.pem from my .crt .key and .ca-bundle from my wildcard cert from COMODO. I have my internal.xml file configured to use wss on 443, and in vars.xml I point ca_certs to /etc/freeswitch/certs where my wss.pem file lives owned by freeswitch:daemon. However, when I try to test it, I get back the default self signed cert, not my cert from wss.pem. nathan@marge cert $ openssl s_client -connect as1-east.illumy1.com:443 CONNECTED(00000003) depth=0 C = US, CN = FreeSWITCH verify error:num=18:self signed certificate verify return:1 depth=0 C = US, CN = FreeSWITCH verify return:1 --- Certificate chain 0 s:/C=US/CN=FreeSWITCH i:/C=US/CN=FreeSWITCH --- Server certificate -----BEGIN CERTIFICATE----- MIIEujCCAqICAQAwDQYJKoZIhvcNAQEFBQAwIjELMAkGA1UEBhMCVVMxEzARBgNV BAMMCkZyZWVTV0lUQ0gwIBcNMTgxMjI3MDEzOTIyWhgPMjExODEyMTAwMTM5MjJa MCIxCzAJBgNVBAYTAlVTMRMwEQYDVQQDDApGcmVlU1dJVENIMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEA/xUekzi8uf0ea+/GreneBm3sm9IsQ7L1Yfha 8hSvxaX8ElZIlUHUudkCHoreUgoN+AX/F/I4BY93zfAooZ0+q7CVLfJiLsnW5+Do 3o0eDXQWQ1qWm1a2tv4h7pFWTM9erGDIharhIUj45CJhtKM2Z5TxbRIp2HtAOMen N5M1v+zni7xKS0AOoY6H3i0qHnAeQt5QrpC11575/+5aEWW777W18v5iup9Cn7sR 4LxCdQrnJ9UzthNDvkLz5jYX10JZibVs/DehURv9jimVUYaan1fOzhDtVQh/av22 m4KlTB8xzPSAm0TooRcB0zNbyXCAbnvl9E67orZrxvTzmaKxaPHkGPTqBN962Ti6 TGSYlz31nKGNeABACSbDSRkRZcnv96+VMo6FKoppHpJISXTZwRQhOJ9Im7HVwISE zqhOgDSMo64DcCyif3LOL/gesRjPkc439HulLikDBBS9oAZq8vNg8x8FPA/urpka I+mLPTiE39o7vlb6CeBbGeQktUTB+egun8sBYi+DHXW4lX07HLFM6lqhqO8ZYNqY 1hEcPZY0GovVNlPVvebCIJhti/bBa/5EAwBGVJnEWjqTTYeIn1jF8eAxAMFHw94P RwWAOUgVmq9c5GuRTaw9QWkYg/4Hr4PojGMAIaD0R6m60fIEGOLkzBEUS1Wa6mqK EZKy6dkCAwEAATANBgkqhkiG9w0BAQUFAAOCAgEAoFXoWVf/in6dYKWgxSIOsUWA yyZiGOexO5P/WW5dVoQ0P67iE2wHkABMTkFe4ir3fHlyeKbbcCB3bU28rsPg/wwo P0TIbKNAucrwZ8JKhVQErri/bCYMuctdEN1YxqgQh4YVHYs2/tLr3koqD73crpUL aiq0DNWxx6nbTu7223b40zvKjzLNcjuD6DnKAeMaSdsYjfDtrLk5D1WzMXmG1jzu wwTAHVn0ru0aiQr3dSpUOD8/V+JqCLO7FbrJL6hpd6NemMasdUjgIr1FenuOmyXn A0PFIfQgW1LBlJP1UEGW+yWnVFBNn6pS5AwreVWpS1Tsewa8TTPB/A7ZUAlUb4Lg RsvaBc/56ACG9X2DqOBeYUaK/1Hio4/0n29EpB0zN2R0PPOV2QzBScMecIqbGyf3 gstrMM8KG0GyZRTVOhElWkcgrxre6jM4bzTtOiaZD752pBrYP4EVGtf+oyC9UlKx 7ruCkYuNgyGzJgFfSC8s8zYOBAged3aggQYAL4k7rG3uUTnqOHmQg6XFghWCvc3j I+TEVKeaGhobcKmZp6CwTjmr63in2D1Kn902wVE6WVdHhJSxT1kuIGf3UYhUWZ6Y iBdtAKKhd8QmUYvhzpEHyTPV9bVrrIJJRQW3kzB8jVuyrSYYWnxibcpVxAE1CyHb IlJagm7ZFZDqZ4Gn4TM= -----END CERTIFICATE----- subject=/C=US/CN=FreeSWITCH issuer=/C=US/CN=FreeSWITCH --- No client certificate CA names sent --- SSL handshake has read 1527 bytes and written 863 bytes --- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : AES256-GCM-SHA384 Session-ID: 99DD9750EDDD173E6E41606FB834F0F5AA4B27AA0CCF8284F8D87F47E607D9A9 Session-ID-ctx: Master-Key: D1F6C0AD00EB7151098BF0DD68670DE9D4631ACED00CE97EAD684B2670BDE283D34FC85CF7D6CED82FB79C68A150988A Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 9a 90 ee 94 ba 4d da e1-d7 c9 6d f1 bb 86 0b 74 .....M....m....t 0010 - 53 d3 62 eb ca 6b 3e 2b-c4 36 f4 34 ff 73 e0 6a S.b..k>+.6.4.s.j 0020 - 79 f7 72 d7 ca 24 fa 60-bb 37 c8 b9 cd df 71 74 y.r..$.`.7....qt 0030 - 00 d8 37 c6 a2 ef dc 49-08 15 36 04 45 58 f5 af ..7....I..6.EX.. 0040 - 0c 09 66 36 98 34 6f d0-6d cb 4a 6e 9e 2a 67 d1 ..f6.4o.m.Jn.*g. 0050 - b2 84 a1 f2 ff 6f 7a 89-6f 92 5f ca 8b 6a 96 d1 .....oz.o._..j.. 0060 - 7a 18 f4 b8 50 8e 31 d1-d0 9f 52 d0 01 43 ba eb z...P.1...R..C.. 0070 - 6b 89 bb 9e 7c 60 dd 16-ce 2e 14 c4 44 ca 32 74 k...|`......D.2t 0080 - da 66 fc 17 ac a3 04 29-3d f6 b8 39 c4 c2 48 81 .f.....)=..9..H. 0090 - 75 a1 2e 93 bc 2d 23 c5-5d 35 1b 88 1e 75 97 ee u....-#.]5...u.. Start Time: 1546611916 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- read:errno=0 ><> nathan stratton

2 2

Fwd: switch_core_session.c:538 Could not locate channel type $
by Nathan Stratton 08 Jan '19

08 Jan '19

New install, I have two users registered and I am trying to call between them. The error I am getting is: 2019-01-03 19:32:16.148530 [DEBUG] switch_ivr_originate.c:2204 Parsing global variables 2019-01-03 19:32:16.148530 [ERR] switch_core_session.c:538 Could not locate channel type $ {sofia_contact(* 2019-01-03 19:32:16.148530 [NOTICE] switch_ivr_originate.c:2944 Cannot create outgoing channel of type [$ {sofia_contact(*] cause: [CHAN_NOT_IMPLEMENTED] 2019-01-03 19:32:16.148530 [DEBUG] switch_ivr_originate.c:3941 Originate Resulted in Error Cause: 66 [CHAN_NOT_IMPLEMENTED] 2019-01-03 19:32:16.148530 [NOTICE] switch_ivr_originate.c:2944 Cannot create outgoing channel of type [user] cause: [CHAN_NOT_IMPLEMENTED] 2019-01-03 19:32:16.148530 [DEBUG] switch_ivr_originate.c:3941 Originate Resulted in Error Cause: 66 [CHAN_NOT_IMPLEMENTED] 2019-01-03 19:32:16.148530 [INFO] mod_dptools.c:3518 Originate Failed. Cause: CHAN_NOT_IMPLEMENTED EXECUTE sofia/internal/1000(a)illumy1.com answer() Any ideas? This has been driving me crazy. ><> nathan stratton

4 4

Missing audio in bridged call
by Riccardo Traverso 08 Jan '19

08 Jan '19

Hi everyone, I'm totally new to FreeSWITCH (and PBX software in general) and I'm trying to build a small directory IVR to start getting the hang of it. I'm currently stuck, and I need your help please. This is the setup. I've got a FreeSWITCH on the first machine with a Lua extension that contains a basic IVR application. When a user calls the IVR and performs a choice, I want to connect him to a specific remote SIP address. I tried with the transfer command at first, but in my understanding I could only use that if I wanted to connect him to another user/extension on the same server, which isn't my case. So I tried with bridging instead. Right now, the IVR doesn't even ask for a choice, it just plays an audio file and tries to connect to a fixed remote address for test, say user(a)example.com, which in turn again just plays a different prompt. When I call the Lua extension I correctly hear the audio of the first prompt, but nothing from the second. I also tried starting voice recognition on user(a)example.com, which works instead. Yet, even though apparently user(a)example.com can hear me through the bridge, I cannot hear his prompt. If i call directly user(a)example.com I hear the prompt correctly. I do not even know where to start from, any advices, please? Which kind of configs or logs would be useful to diagnose the problem? Thanks in advance! Below is the code to my Lua extension. Best regards, Riccardo session:answer() session:setAutoHangup(false); playback("/some/welcome/audio.wav") local session1 = freeswitch.Session("sofia/external/user(a)example.com"); freeswitch.bridge(session, session2);

2 1

Cipher Suite not working
by Rex Lin (林昱頡) 08 Jan '19

08 Jan '19

Hello, Currently we are using TLS for client/server communication, I would like to do debug using wireshark but got problem in decrypting. I have seen Server Hello with only one single Cipher Suite of ECDHE, I've tried changing "vars" into AES256-SHA, though with the same result; I wonder if anything had been missed or I'm in a wrong way? Below is the detail, TKS for any advice. Scenario: Client --> Kamailio PSTN --> External in FreeSWITCH FreeSWITCH version: 1.6.20-37-987c9b9~64bit (-37-987c9b9 64bit) ----------------------------Wireshark debug---------------------------- private key: agent.pem FreeSWITCH to Kamailio Cipher Suite : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ----------------------------vars.xml--------------------------------------- <X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=AES256-SHA"/> Best Regards, Rex Lin

1 0

Presence not working on resubscribe
by mittali jangid 07 Jan '19

07 Jan '19

Hi, I am working on presence in polycom phones. I have BLF key for fifo-orbits. Presence is working fine when call is parked in orbit. But if phone has lower subscription-expiry and phone resubscribes, then freeswitch responds with "Terminated" state notify. Same is happening for user-directory extension number set as BLF in polycom phones. Also if i add BLF for either fifo-orbit or extension when any call is parked or extension is attending call respectively, presence is not working as per expectation. I verified this in latest freeswitch version 1.8.2 and also Master pull. I would like to know why it is behaving this way. Below link also faced similar issue, but it is still not resolved : http://lists.freeswitch.org/pipermail/freeswitch-users/2013-October/100598.… Your help is much appreciated. Let me know what information is required from my end. Thanks and regards, Mittali Jangid

1 1

Cipher Suite not working
by Rex Lin (林昱頡) 07 Jan '19

07 Jan '19

Currently we are using TLS for client/server communication, I would like to do debug using wireshark but got problem in decrypting. I have seen Server Hello with only one single Cipher Suite of ECDHE, I’ve tried changing “vars” into AES256-SHA, though with the same result; I wonder if anything had been missed or I’m in a wrong way? Below is the detail, TKS for any advice. Scenario: Client --> Kamailio PSTN --> External in FreeSWITCH FreeSWITCH version: 1.6.20-37-987c9b9~64bit (-37-987c9b9 64bit) ----------------------------Wireshark debug---------------------------- private key: agent.pem FreeSWITCH to Kamailio Cipher Suite : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ----------------------------vars.xml--------------------------------------- <X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=AES256-SHA"/> Best Regards, Rex Lin

1 0

about mod_av and ffmpeg/libav
by Madovsky 04 Jan '19

04 Jan '19

Hi, what is today the compatibility status fo FS last git and libav version? Also is it compatible with ffmpeg too? thanks

4 13

spandsp_start_dtmf - same inband DTMF is detected multiple times if current playback is stopped with uuid_break
by Harangozó, László 03 Jan '19

03 Jan '19

Hi, Any suggestions would be welcome with the following scenario: External app managing calls trough ESL We have to detect inband DTMF digits (we generally try to use a configuration where we don't have to deal with inband DTMF digits, but in some rare cases it cannot be avoided). There are cases when a playback has to be stopped when a certain digit is received. Inband DTMFs are detected with spandsp_start_dtmf. So the following happens: 1. Inbound call answered 2. spandsp_start_dtmf called 3. A file is being played 4. Client starts to send an inband DTMF 5. After a very short time FreeSwitch issues the DTMF event 6. External app stops the playback with uuid_break 7. External app starts to play a different file 8. Freeswitch detects the same digit again (which is still present in the RTP, the DTMF is on for roughly 400ms, and only ~190ms has elapsed since step 5) The scenario is reproducible and happens in a consistent way. The inband DTMF is continuous. FreeSwitch reports only 1 DTMF event if the play is not interrupted with uuid_break. Is it possible to avoid this sort of multiple detection? Or do I have to handle this in the external app level? Is this an issue I should report to JIRA? *Hari*

2 1

How can we make Freeswitch work with a verto client running on Edge?
by Alejandro Castera 03 Jan '19

03 Jan '19

Hello all, We can use the verto communicator client to join a conference handled by our own Freeswitch server. It works on Chrome, Firefox and Opera, on which we can connect ok and get audio+video. But it does NOT work on Edge. The candidates Edge provides are the following: candidate:1 1 UDP 2130706431 192.168.0.7 63832 typ host candidate:2 1 TCP 1684798975 192.168.0.7 63832 typ srflx raddr 192.168.0.7 rport 63832 tcptype active So for for every local IP, Edge generates 2 candidates: 1 host candidate, and 1 srflx candidate. The srvflx candidate is built wrong on purpose (transport address == related address). I guess they do that so that when the ICE connection checks take place, the server side can "learn" a new prflx candidate (see RFC5245, section 7.2.1.3) I have tested the same scenario using a server which makes use of the libnice library for the ICE implementation, and it works!!! No TURN server is being used, no STUN server is being used, the candidates Edge sends are the 2 above (which do not contain a public IP) and still the server generates a prflx candidate and the connection is established perfectly. But when using our Freeswitch server (which does not make use of the libnice library for ICE) the connection does not work. Then again, the funny thing is that if we use the cantina.freeswitch.org Freeswitch server, then it DOES work! So there must be something in the code/configuration that could be done so that the Freeswitch server can "learn" a prflx candidate from those Edge is sending out. Could anyone help us? Alex

3 3