October 2019 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Re: [Freeswitch-users] Multiple History Info header
by Giri 24 Oct '19

24 Oct '19

*I am trying to export sip_h_Diversion header twice but not working, only one header is sent out and not two. * *If I use export with “,” then I get the following results: *>* Diversion: <sip:19082302337 at 216.1.185.103 <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>>;reason=user-busy;counter=3;privacy=off,<sip:13216938059 at 216.1.185.103 <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>>;reason=no-answer;counter=1;privacy=off *> >* <extension name="public_did"> *>* <condition field="destination_number" expression="^9999(\d{10})$"> *> >* <action application="set" data="ocn=18005551212"/> *>* <action application="set" data="rdn=18005552323"/> *> >* <action application="export" data="sip_h_Diversion =<sip:${ocn}@${network_addr}>;reason=user-busy;counter=3;privacy=off, <sip:${rdn}@${network_addr}>;reason=no-answer;counter=1;privacy=off "/> *> >* <action application="set" data="hangup_after_bridge=true" /> *>* <action application="set" data="continue_on_fail=true"/> *> >* <action application="transfer" data="1001 XML default"/> *>* </condition> *>* </extension>* With Best Regards, Girish Dharmaraj On Sun, Oct 6, 2019 at 12:47 PM Giri <girish.dharmaraj(a)gmail.com> wrote: > *I am trying to export sip_h_Diversion header twice but not working, only one header is sent out and not two. * > > *If I use export with “,” then I get the following results: > *>* Diversion: <sip:19082302337 at 216.1.185.103 <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>>;reason=user-busy;counter=3;privacy=off,<sip:13216938059 at 216.1.185.103 <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>>;reason=no-answer;counter=1;privacy=off > *> >* <extension name="public_did"> > *>* <condition field="destination_number" expression="^9999(\d{10})$"> > *> >* <action application="set" data="ocn=18005551212"/> > *>* <action application="set" data="rdn=18005552323"/> > *> >* <action application="export" data="sip_h_Diversion =<sip:${ocn}@${network_addr}>;reason=user-busy;counter=3;privacy=off, <sip:${rdn}@${network_addr}>;reason=no-answer;counter=1;privacy=off "/> > *> >* <action application="set" data="hangup_after_bridge=true" /> > *>* <action application="set" data="continue_on_fail=true"/> > *> >* <action application="transfer" data="1001 XML default"/> > *>* </condition> > *>* </extension>* > > > With Best Regards, > Girish Dharmaraj > > > > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. > www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> > <#m_6076873152175307791_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Sat, Oct 5, 2019 at 12:41 AM Giri <girish.dharmaraj(a)gmail.com> wrote: > >> when I add a multiple header with comma separated only one header is >> added, is there anything wrong with my syntax ? >> >> sip_h_History-Info=<sip:${CF_caller_id_number}@198.18.181.6;user=phone>;index=1;ms-retarget-reason=forwarding, >> <sip:${callee_id_number}@198.18.181.6;user=phone>;index=1.1; >> >> The Result is showing in one header. >> >> >> With Best Regards, >> Girish Dharmaraj >> >

2 1

Cancel X-Reason between servers
by Jon Schøpzinsky 24 Oct '19

24 Oct '19

Hi, We have the following setup, with a queue server, running our own queue software, a main switch and a SBC. Queue FreeSWITCH -> Master FreeSWITCH -> OpenSIPS -> UA When a queue dials multiple UA’s, an one of them answers, the rest is correctly sent a CANCEL with the LOOSE_RACE as X-Reason header. This is sent from the Queue FreeSWITCH to the Master FreeSWITCH, but when the Master FreeSWITCH sends this on to the OpenSIPS, the X-Reason header gets changed to ORIGINATOR_CANCEL. I found the code that does this, and it seems to be this block in switch_ivr_originate: https://github.com/signalwire/freeswitch/blob/f9990221e6094886066ec2bf96856… <https://github.com/signalwire/freeswitch/blob/f9990221e6094886066ec2bf96856…> This always sets the reason to be ORIGINATOR_CANCEL, no matter what was set by the upstream server. I know FreeSWITCH is not supposed behave like a proxy, and even OpenSIPS overwrites CANCEL reasons in its standard configuration, but would there be interest in us implementing proxying functionality, using a configuration item or channel variable, enabling this reason to be proxied through? Kind Regards Jon Schøpzinsky

2 1

CS_INIT,,,,,,,,DOWN
by Max Solaris 24 Oct '19

24 Oct '19

Hi, I’m a long time user with Freeswitch, however I’m getting a strange issue I never found over past years. If I take a look at fs_cli console and look at “show calls” result I can see a great list of calls with state: CS_INIT,,,,,,,,DOWN This call count is increasing and is eating hardware resources until CPU / MEMORY leave the server unresponsive… How to clear these “zombie calls?” Is there an explaination for calls being frozen with this state? Just to clarify I’m using FS 1.6.20 git 43a9fe with Debian 8 ( I know it’s old, but can’t update for policy reason.. ) Thank you for your help, FS rocks! Max

2 5

call drop because of no write codec, incompatible_destination
by António Silva 24 Oct '19

24 Oct '19

Hi, I'm seeing multiple calls drop with incompatible_destination, i try to call again the same destination and it works fine. it gets me crazy... In logs i see the error, "has no write codec", in the capture i see the negotiation both sides have codecs, they are correctly configure in directory. what could be causing this? i'm using version 1.8.6 Part of the LOG where the error happens: f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:37.694352 [ALERT] switch_core_state_machine.c:701 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 session thread sleep state: CS_CONSUME_MEDIA! f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.794408 [ALERT] switch_core_session.c:1130 Send signal sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [BREAK] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.794408 [ALERT] switch_core_session.c:1130 Send signal sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [BREAK] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.794408 [ALERT] switch_core_state_machine.c:705 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 session thread wake state: CS_CONSUME_MEDIA! f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.814367 [ALERT] switch_core_media.c:486 Looking for zrtp-hash f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.814367 [ALERT] switch_core_media.c:439 Deciding whether to pass zrtp-hash between legs f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.814367 [ALERT] switch_core_media.c:441 CF_ZRTP_PASSTHRU_REQ not set, so not propagating zrtp-hash f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.834519 [DEBUG] sofia.c:7325 Channel sofia/1-perfil-fija/sip:11@131.179.185.131:5112 entering state [completing][200] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.834519 [DEBUG] sofia.c:7335 Remote SDP: f39e569f-5184-481a-9f67-6185367e2829 v=0 f39e569f-5184-481a-9f67-6185367e2829 o=11 5008 38 IN IP4 192.168.100.11 f39e569f-5184-481a-9f67-6185367e2829 s=Mapping f39e569f-5184-481a-9f67-6185367e2829 c=IN IP4 192.168.100.11 f39e569f-5184-481a-9f67-6185367e2829 t=0 0 f39e569f-5184-481a-9f67-6185367e2829 m=audio 5008 RTP/AVP 0 101 f39e569f-5184-481a-9f67-6185367e2829 a=rtpmap:0 PCMU/8000 f39e569f-5184-481a-9f67-6185367e2829 a=rtpmap:101 telephone-event/8000 f39e569f-5184-481a-9f67-6185367e2829 a=fmtp:101 0-16 f39e569f-5184-481a-9f67-6185367e2829 a=ptime:20 f39e569f-5184-481a-9f67-6185367e2829 f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.834519 [NOTICE] sofia.c:7338 Pre-Answer sofia/1-perfil-fija/sip:11@131.179.185.131:5112! f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.934371 [ALERT] switch_core_session.c:2662 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 Send KeyFrame f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.934371 [DEBUG] switch_core_session.c:2825 EXECUTE [depth=1] sofia/1-perfil-fija/sip:11@131.179.185.131:5112 lua(execute_on_ring_b.lua) f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.934371 [ALERT] switch_core_session.c:2889 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 receive message [APPLICATION_EXEC] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.934371 [ALERT] switch_core_session.c:1047 Send signal sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [BREAK] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.954358 [ALERT] switch_core_session.c:1047 Send signal sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [BREAK] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:41.954358 [ALERT] switch_ivr_originate.c:4136 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 receive message [AUDIO_SYNC] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.034370 [DEBUG] switch_cpp.cpp:1187 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 destroy/unlink session from object f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.034370 [ALERT] switch_core_session.c:2905 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 receive message [APPLICATION_EXEC_COMPLETE] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.034370 [DEBUG] switch_channel.c:3537 (sofia/1-perfil-fija/sip:11@131.179.185.131:5112) Callstate Change RINGING -> EARLY f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] sofia.c:7338 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 receive message [PROGRESS_EVENT] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] switch_core_media.c:486 Looking for zrtp-hash f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] switch_core_media.c:439 Deciding whether to pass zrtp-hash between legs f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] switch_core_media.c:441 CF_ZRTP_PASSTHRU_REQ not set, so not propagating zrtp-hash f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] switch_ivr_bridge.c:1650 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 receive message [AUDIO_SYNC] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] switch_core_state_machine.c:701 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 session thread sleep state: CS_CONSUME_MEDIA! f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] switch_ivr_bridge.c:1751 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 receive message [BRIDGE] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] switch_core_session.c:981 Send signal sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [BREAK] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [DEBUG] switch_ivr_bridge.c:1795 (sofia/1-perfil-fija/sip:11@131.179.185.131:5112) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.094512 [ALERT] switch_core_session.c:1480 Send signal sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [BREAK] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.114382 [ALERT] switch_core_state_machine.c:705 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 session thread wake state: CS_CONSUME_MEDIA! f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.114382 [DEBUG] switch_core_state_machine.c:584 (sofia/1-perfil-fija/sip:11@131.179.185.131:5112) Running State Change CS_EXCHANGE_MEDIA (Cur 242 Tot 835614) f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.114382 [DEBUG] switch_core_state_machine.c:653 (sofia/1-perfil-fija/sip:11@131.179.185.131:5112) State EXCHANGE_MEDIA f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.114382 [ALERT] switch_core_state_machine.c:653 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 Send KeyFrame f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.114382 [DEBUG] mod_sofia.c:657 SOFIA EXCHANGE_MEDIA f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.134357 [ERR] switch_core_media.c:15507 sofia/1-perfil-fija/sip:11@131.179.185.131:5112 has no write codec. f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.134357 [NOTICE] switch_core_media.c:15508 Hangup sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [CS_EXCHANGE_MEDIA] [INCOMPATIBLE_DESTINATION] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.134357 [ALERT] switch_channel.c:3346 Send signal sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [KILL] f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.134357 [DEBUG] mod_hash.c:297 Usage for total_account:11@clinicalluch.daratel.com is now 0 f39e569f-5184-481a-9f67-6185367e2829 2019-10-21 11:50:42.134357 [ALERT] switch_core_session.c:1480 Send signal sofia/1-perfil-fija/sip:11@131.179.185.131:5112 [BREAK] -- Saludos / Regards / Cumprimentos António Silva

1 0

Voicemail to email with user XML from Lua
by Paul Smith 24 Oct '19

24 Oct '19

Hi, I'm new to freeswitch but have been playing with configs and reading confluence and the Packt book for a few weeks. Is there a difference between setting up a user as static XML and getting the user XML snippet from a lua script? I can't seem to get voicemail to email to work if the user XML snippet is generated by lua, but it works fine if I have the static xml in a file. The following fs_cli command to post the email works fine. So the mail server, templates etc are OK. vm_fsdb_msg_email default 123 1039 f8df8b69-21d7-4339-836e-777dbec87db3 customer1@mytestdomain I suspect that loading the XML at startup as opposed to generating snippet from lua is significant? This static user directory/123/1039.xml works: <include> <user id="1039"> <params> <param name="password" value="$${default_password}"/> <param name="vm-password" value="1000"/> <param name="vm-mailto" value="testing(a)mydomain-ni.com" /> <param name="vm-mailfrom" value="paul(a)mydomain-ni.com" /> <param name="vm-email-all-messages" value="true" /> </params> <variables> <variable name="toll_allow" value="domestic,international,local"/> <variable name="accountcode" value="1000"/> <variable name="user_context" value="default"/> <variable name="effective_caller_id_name" value="Extension 1000"/> <variable name="effective_caller_id_number" value="1039"/> <variable name="outbound_caller_id_name" value="$${outbound_caller_name}"/> <variable name="outbound_caller_id_number" value="$${outbound_caller_id}"/> <variable name="callgroup" value="techsupport"/> </variables> </user> </include> Email is sent and log shows: *2019-10-24 09:38:21.955085 [DEBUG] mod_voicemail.c:1952 Update MWI: Message Account 1039@123 2019-10-24 09:38:21.955085 [DEBUG] mod_voicemail.c:1953 Update MWI: Voice Message 28/1 2019-10-24 09:38:22.875122 [DEBUG] switch_utils.c:1300 Emailed data to [testing(a)mydomain-ni.com] 2019-10-24 09:38:22.875122 [DEBUG] mod_voicemail.c:3042 Sending message to testing(a)mydomain-ni.com e5e12f00-e39b-4eda-8e27-a22adc14ddb3 2019-10-24 09:38:22.875122 [DEBUG] switch_ivr_play_say.c:70 No language specified - Using [en] * But generating a very similar XML from LUA... the voicemail is saved, and MWI activated. But no email is sent. 2019-10-24 10:03:18.271420 [DEBUG] mod_voicemail.c:1925 Update MWI: Processing for 1039@123 in inbox 2019-10-24 10:03:18.271420 [NOTICE] switch_cpp.cpp:1443 Debug directory xml snippet: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <document type="freeswitch/xml"> <section name="directory"> <domain name="123"> <user id="1039"> <params> <param name="password" value="sjkdfsjhdf4895sdkjh8934tsdvsjdkgsf"/> <param name="vm-password" value="0000"/> <param name="vm-mailto" value="checkto(a)mydomain-ni.com"/> <param name="vm-mailfrom" value="voicemail(a)vociemail.co.uk"/> <param name="vm-email-all-messages value="true"/>   </params> <variables> <variable name="toll_allow" value="domestic,international,local"/> <variable name="user_context" value="default"/> <variable name="accountcode" value="1000"/> <variable name="user_context" value="default"/> <variable name="effective_caller_id_name" value="Extension 1000"/> <variable name="effective_caller_id_number" value="1039"/> <variable name="outbound_caller_id_name" value="Frank"/> <variable name="outbound_caller_id_number" value="10390"/> <variable name="callgroup" value="techsupport"/> </variables> </user> </domain> </section> </document> 2019-10-24 10:03:18.271420 [DEBUG] mod_voicemail.c:1950 Update MWI: Messages Waiting yes 2019-10-24 10:03:18.271420 [DEBUG] mod_voicemail.c:1951 Update MWI: Update Reason NEW 2019-10-24 10:03:18.271420 [DEBUG] mod_voicemail.c:1952 Update MWI: Message Account 1039@123 *2019-10-24 10:03:18.271420 [DEBUG] mod_voicemail.c:1953 Update MWI: Voice Message 29/1* *2019-10-24 10:03:18.271420 [DEBUG] switch_ivr_play_say.c:70 No language specified - Using [en]* 2019-10-24 10:03:18.291420 [DEBUG] switch_ivr_play_say.c:250 Handle play-file:[voicemail/vm-goodbye.wav] (en:en) 2019-10-24 10:03:18.291420 [DEBUG] switch_ivr_play_say.c:1492 Codec Activated L16@8000hz 1 channels 20ms

1 0

ulimits
by Renato Gallo 24 Oct '19

24 Oct '19

hello, I have installed freeswitch on a debian buster successfully (using the debs). I have set up the ulimits in the freeswitch.service, in the /etc/profile... around everywhere but the Max open files still equals to 999999 where on earth freeswitch takes that value ? Renato Gallo

2 1

Freeswitch not sending full capabilities in 200OK after noSDP reInvite
by Skaba Tomasz 24 Oct '19

24 Oct '19

Hi, We are struggling with an isssue related to late-offer reInvite. The scenario is as follows: (A) -- INVITE (SDP1) --> (Freeswitch) (A) <-- 200OK (SDP2) - (Freeswitch) (A) - ACK --> (Freeswitch) (A) - INVITE (noSDP) --> (Freeswitch) (A) <-- 200OK (SDP3) - (Freeswitch) For clarity i skipped non important messages. The important thing is that when Freeswitch receives noSDP reInvite it responds with last negotiated SDP (same codecs list) so in above scenario SDP3=SDP2. According to RFC UAS should send its full capabilities so i think Freeswitch should send as many codecs as it would send in response to initial Invite in late-offer. Moreover when Freeswitch receives an initial noSDP Invite it respond with it's full capabilities which is desired behaviour. The version of Freeswitch we are using is 1.2.10 but i confirmed on newest version that the behaviour is the same. I would appreciate any clues and hints how to deal with this issue. Best Regards Tomasz Skaba Projektant Pion Telekomunikacji i Mediów Asseco Poland S.A. ul. Sadowa 29 33-100 Tarnów mobile: 691 996 608 <mailto:tomasz.skaba@asseco.pl> tomasz.skaba(a)asseco.pl asseco.pl Asseco Poland S.A. z siedzibą w Rzeszowie, ul. Olchowa 14, 35-322 Rzeszów, tel.: +48 17 888 55 55, fax: +48 17 888 55 50, <http://www.asseco.pl/> www.asseco.pl, e-mail: <mailto:info@asseco.pl> info(a)asseco.pl, NIP: 522-000-37-82, REGON: 010334578, Sąd Rejonowy w Rzeszowie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000033391. Kapitał zakładowy w wysokości 83.000.303,00 PLN jest opłacony w całości. Powyższa korespondencja przeznaczona jest wyłącznie dla osoby lub podmiotu, do którego jest adresowana i może zawierać informacje o charakterze poufnym lub zastrzeżonym. Nieuprawnione wykorzystanie informacji zawartych w wiadomości e-mail przez osobę lub podmiot nie będący jej adresatem jest zabronione odpowiednimi przepisami prawa. Odbiorca korespondencji, który otrzymał ją omyłkowo, proszony jest o niezwłoczne zawiadomienie nadawcy drogą elektroniczną lub telefonicznie i usunięcie tej treści z poczty elektronicznej. Dziękujemy. Asseco Poland S.A. This information is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Unauthorised use of this information by person or entity other than the intended recipient is prohibited by law. If you received this by mistake, please immediately contact the sender by e-mail or by telephone and delete this information from any computer. Thank you. Asseco Poland S.A.

2 1

mod_syslog doubts regarding docs and usage
by Joel Serrano 23 Oct '19

23 Oct '19

Hi all, I'm trying to send to syslog any log msg with a level or WARNING+ I'm finding inconsistent information and behavior though... 1- From the docs: https://freeswitch.org/confluence/display/FREESWITCH/mod_syslog *...There is currently no way to insert the level, nor to change the date format...* 2- From the conf file: https://github.com/signalwire/freeswitch/blob/master/conf/vanilla/autoload_… *... <param name="loglevel" value="warning"/>...* But still, even having "warning" as the loglevel, I still get on syslog any msg (INFO, NOTICE, etc...) My config looks like: <configuration name="syslog.conf" description="Syslog Logger"> <settings> <param name="facility" value="user"/> <param name="ident" value="freeswitch"/> <param name="loglevel" value="warning"/>  <param name="uuid" value="true"/> </settings> </configuration> Any suggestions? Thanks, Joel.

1 0

Un-authenticated downstream users
by Martyn Davies 23 Oct '19

23 Oct '19

I need to achieve a setup where a VoIP gateway box is downstream of Freeswitch but will not authenticate, i.e. calls (INVITES) from this box ( a fixed IP address ) to port 5060 on FS will get routed to the upstream side (I have an upstream gateway defined in sip_profiles), and also all calls from the upstream side will get routed back to the downstream gateway box. This gateway box does not have the configuration to REGISTER, but will simply fling out an INVITE whenever a call is initiated. I don't need to specify specific phone numbers in the FS dialplan (unless this is required by FS). Can anyone suggest a good way to achieve this in the Freeswitch dialplan? Regards, Martyn

3 2

Random TCP Ports
by srdrztrk 23 Oct '19

23 Oct '19

Hi, I've been testing version 1.10 for a while and trying to close unused ports. When i run netstat command, two random TCP ports (especially between 30000-46000) are open . I tried a lot of configuration to disable them. Why are these ports are open? How can i disable them? (Module or configuration) Thanks.

2 1