- FreeSWITCH-users - FreeSWITCH Mailing Lists

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

ESL connection appears to hang on bgapi originate - isn't the whole point of it being in the background?
by Michael Avers 23 Oct '19

23 Oct '19

Hello, When an ESL connection is opened to FS, there is no way to close the connection with "exit" until the A Leg of a bgapi originate answers or rejects the call, or the originate times out. I thought bgapi is supposed to be truly non-blocking? When the bgapi originate is executed, FS returns the expected *Reply-Text: +OK Job-UUID *response, I am able to continue to communicate with FS over the ESL connection while the originate is in progress and the A Leg is ringing, and get responses to other standard commands. It all works, except for "exit", to which FS responds with *Reply-Text: +OK bye *but does not actually proceed to close the connection and issue a *Content-Type: text/disconnect-notice *response until the (supposedly in the background) originate is rejected or answered. However, after the exit command, ESL will no longer process any new commands, it just hangs until the originate has some kind of result. I tested with FS 1.6.2, a 1.8.x instance, and also latest master just now. This is an actual telnet ESL connection, just added a comment to indicate where it appears to "hang": Trying 45.45.45.45... Connected to 45.45.45.45. Escape character is '^]'. Content-Type: auth/request auth ClueCon Content-Type: command/reply Reply-Text: +OK accepted bgapi originate {origination_caller_id_number='4154446666',origination_caller_id_name='Callback',originate_timeout=20}user/1000(a)sip.domain.com 808080 XML sip.domain.com Content-Type: command/reply Reply-Text: +OK Job-UUID: e53965cd-b0c0-4c39-99ad-946048082ef2 Job-UUID: e53965cd-b0c0-4c39-99ad-946048082ef2 exit Content-Type: command/reply Reply-Text: +OK bye *<< here it pauses until originate times out, gets rejected, or answered by the destination user >>* Content-Type: text/disconnect-notice Content-Length: 67 Disconnected, goodbye. See you at ClueCon! http://www.cluecon.com/ Connection closed by foreign host. Is this expected behavior? I also tested with ignore_early_media on/off just in case, same result. Thanks Mike

2 2

Why did this call "drop"
by Sean Devoy 23 Oct '19

23 Oct '19

Hi, My user (who has reported no answer calls as "dropped" in the past) has reported a call to this number dropped twice while still ringing. Can some tell me what happened? It looks like the dialed number has a timeout for time allowed to ring or something similar???? 61d26afb-35dc-4171-ab41-5a881489bee0 2019-10-11 18:47:51.014455 [DEBUG] switch_core_codec.c:248 sofia/internal/111(a)my-sip.domain.com Restore previous codec PCMU:0. 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [NOTICE] switch_ivr_originate.c:3713 Hangup sofia/external/13032672947 [CS_CONSUME_MEDIA] [NO_ANSWER] 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:585 (sofia/external/13032672947) Running State Change CS_HANGUP (Cur 2 Tot 8701) 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:848 (sofia/external/13032672947) Callstate Change RINGING -> HANGUP 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:850 (sofia/external/13032672947) State HANGUP 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] mod_sofia.c:460 Channel sofia/external/13032672947 hanging up, cause: NO_ANSWER 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] mod_sofia.c:528 Sending CANCEL to sofia/external/13032672947 61d26afb-35dc-4171-ab41-5a881489bee0 2019-10-11 18:47:51.014455 [INFO] mod_dptools.c:3631 Originate Failed. Cause: NO_ANSWER 61d26afb-35dc-4171-ab41-5a881489bee0 2019-10-11 18:47:51.014455 [NOTICE] switch_channel.c:4941 Hangup sofia/internal/111(a)my-sip.domain.com [CS_EXECUTE] [NO_ANSWER] 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:60 sofia/external/13032672947 Standard HANGUP, cause: NO_ANSWER 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:850 (sofia/external/13032672947) State HANGUP going to sleep 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:620 (sofia/external/13032672947) State Change CS_HANGUP -> CS_REPORTING 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:585 (sofia/external/13032672947) Running State Change CS_REPORTING (Cur 2 Tot 8701) 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:936 (sofia/external/13032672947) State REPORTING 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:174 sofia/external/13032672947 Standard REPORTING, cause: NO_ANSWER 3c6a08bb-4045-45c9-acdd-9e14aba0e522 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:936 (sofia/external/13032672947) State REPORTING going to sleep 61d26afb-35dc-4171-ab41-5a881489bee0 2019-10-11 18:47:51.014455 [DEBUG] switch_core_session.c:2905 sofia/internal/111(a)my-sip.domain.com skip receive message [APPLICATION_EXEC_COMPLETE] (channel is hungup already) 61d26afb-35dc-4171-ab41-5a881489bee0 2019-10-11 18:47:51.014455 [DEBUG] switch_core_state_machine.c:651 (sofia/internal/111(a)my-sip.domain.com) State EXECUTE going to sleep

3 2