- FreeSWITCH-users - FreeSWITCH Mailing Lists

Client gets hang-up after 32 seconds
by Charles Bujold 27 Apr '15

27 Apr '15

We have an extension that we can call and can talk with no problems. However if the extension calls us, he gets connected and we can only talk for 32 seconds before the call gets terminated. We looked at the log and are unable to identify the reason why he cannot call us but that we can call him. The error seems to be that when he calls Freeswitch for some reason sets a timeout of 30 seconds (Setting leg timeout to 30) See log below. Please help. How can we fix this? Thanks Charles 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 o=FreeSWITCH 1430114648 1430114650 IN IP4 156.34.240.101 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 s=FreeSWITCH 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 c=IN IP4 156.34.240.101 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 t=0 0 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 m=audio 25974 RTP/AVP 0 101 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=rtpmap:0 PCMU/8000 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=rtpmap:101 telephone-event/8000 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=fmtp:101 0-16 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=ptime:20 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 a=sendrecv 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:908 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:1053 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [NOTICE] switch_ivr_originate.c:3522 Channel [sofia/internal/425(a)192.168.20.153] has been answered 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_channel.c:3689 (sofia/internal/425(a)192.168.20.153) Callstate Change EARLY -> ACTIVE 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] sofia.c:6614 Channel sofia/internal/425(a)192.168.20.153 entering state [completed][200] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_ivr_originate.c:3580 Originate Resulted in Success: [sofia/internal/sip:200@192.168.20.150:5060] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_ivr_originate.c:2847 sofia/internal/sip:200@192.168.20.150:5060 Setting leg timeout to 30 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_ivr_originate.c:3580 Originate Resulted in Success: [sofia/internal/sip:200@192.168.20.150:5060] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:908 Send signal sofia/internal/sip:200@192.168.20.150:5060 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:908 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_ivr_bridge.c:1465 (sofia/internal/sip:200@192.168.20.150:5060) State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/sip:200@192.168.20.150:5060 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_core_state_machine.c:472 (sofia/internal/sip:200@192.168.20.150:5060) Running State Change CS_EXCHANGE_MEDIA b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] switch_core_state_machine.c:538 (sofia/internal/sip:200@192.168.20.150:5060) State EXCHANGE_MEDIA b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.785852 [DEBUG] mod_sofia.c:594 SOFIA EXCHANGE_MEDIA b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:04.845827 [DEBUG] switch_rtp.c:5853 Correct ip/port confirmed. 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.785826 [DEBUG] switch_core_session.c:1053 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.785826 [DEBUG] switch_core_session.c:1053 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] sofia.c:6614 Channel sofia/internal/425(a)192.168.20.153 entering state [terminating][0] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [NOTICE] sofia.c:7530 Hangup sofia/internal/425(a)192.168.20.153 [CS_EXECUTE] [NORMAL_UNSPECIFIED] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] switch_channel.c:3222 Send signal sofia/internal/425(a)192.168.20.153 [KILL] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] mod_hash.c:298 Usage for 192.168.20.153_200 is now 0 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.805822 [DEBUG] switch_ivr_bridge.c:660 BRIDGE THREAD DONE [sofia/internal/425(a)192.168.20.153] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.805822 [DEBUG] switch_ivr_bridge.c:690 Send signal sofia/internal/sip:200@192.168.20.150:5060 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:579 sofia/internal/425(a)192.168.20.153 ending bridge by request from write function b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:660 BRIDGE THREAD DONE [sofia/internal/sip:200@192.168.20.150:5060] 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:690 Send signal sofia/internal/425(a)192.168.20.153 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [NOTICE] switch_ivr_bridge.c:754 Hangup sofia/internal/sip:200@192.168.20.150:5060 [CS_EXCHANGE_MEDIA] [NORMAL_CLEARING] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_channel.c:3222 Send signal sofia/internal/sip:200@192.168.20.150:5060 [KILL] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/sip:200@192.168.20.150:5060 [BREAK] b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_state_machine.c:538 (sofia/internal/sip:200@192.168.20.150:5060) State EXCHANGE_MEDIA going to sleep b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_state_machine.c:472 (sofia/internal/sip:200@192.168.20.150:5060) Running State Change CS_HANGUP b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_state_machine.c:735 (sofia/internal/sip:200@192.168.20.150:5060) Callstate Change ACTIVE -> HANGUP b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:1563 sofia/internal/sip:200@192.168.20.150:5060 skip receive message [UNBRIDGE] (channel is hungup already) 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.825829 [DEBUG] switch_ivr_bridge.c:1566 sofia/internal/425(a)192.168.20.153 skip receive message [UNBRIDGE] (channel is hungup already) b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] switch_core_state_machine.c:737 (sofia/internal/sip:200@192.168.20.150:5060) State HANGUP b8e098cc-82a9-4128-992e-a21690707fb3 2015-04-27 10:17:36.825829 [DEBUG] mod_sofia.c:413 Channel sofia/internal/sip:200@192.168.20.150:5060 hanging up, cause: NORMAL_CLEARING 6d0e7ed5-6078-4a31-9d6e-0e7d239c3579 2015-04-27 10:17:36.825829 [DEBUG] switch_core_session.c:2893 sofia/internal/425(a)192.168.20.153 skip receive message [APPLICATION_EXEC_COMPLETE] (channel is hungup already)

2 1

Need cluster architecture suggestion
by Samir Doshi 27 Apr '15

27 Apr '15

Hi Guys, What will be the best setup architecture to handle 50k subscriber registration and approximate 30k concurrent calls? We are planning to use opensips/kamailio proxy server for load balance & to handle registration and multiple freeswitch servers to handle media. Database will be MySQL. Is this good way? OR anybody have any other proposed architecture which can be helpful? Moreover Is there any way we can change codec realtime based on internet connectivity speed? Please let us know your thoughts. Thanks in advance.

8 16

Confirmation of ICE connectivity check success
by Oleg Stolyar 27 Apr '15

27 Apr '15

Hi guys, Is there something in FreeSWITCH logs or events I can use to confirm whether the ICE connectivity check ( https://tools.ietf.org/html/rfc5245#section-2.2) succeeded and what candidate pair was chosen? If it did not succeed, is there a way to see the attempted candidate pair and most importantly to determine for each pair what direction the connectivity failed? This is for WebRTC, if it makes a difference.

1 1

Re: [Freeswitch-users] Need cluster architecture suggestion
by Luis Azedo 27 Apr '15

27 Apr '15

take a look at kazoo https://github.com/2600hz/kazoo Best

1 0

[Warning][switch_core_media.c:1945 Changing current codec to PCMU (payload type 0)]
by Bilal Abbasi 27 Apr '15

27 Apr '15

Hi Brain, Actully i am calling through SIPP, i will take tcpdump and will let you that actually voice works or not, But i am planing to get rid of this warning, i am assuming that this will not make a better stress testing results. Regards Bilal Abbasi

1 0

transfer aleg via ${dial-string}
by Sergey Safarov 26 Apr '15

26 Apr '15

I want emulate REFER message from bleg via ${dial-string}. Please help me find how to do it. I try 1) originate sofia/internal/sip:1000@8.8.8.8 &bridge({execute_on_ring='transfer 1001 XML default'}loopback/9180/default) 2) originate sofia/internal/sip:1000@8.8.8.8 &bridge({execute_on_ring='transfer 1001 XML default'}sofia/internal/ sip:1002@8.8.8.8) In both cases all leg hangup. Also two question: 1) can be lua or other scripting language used to emulate endpoint (implement endpoint interface)? 2) how can be realized "execute_on_channel_create_failure" logic similarity "execute_on_ring". Sergey

1 1

Music on Hold working only in one direction
by Paul Atreides 26 Apr '15

26 Apr '15

Hi, my music on hold is only working in one direction. When I call someone everything is working. But when I get called from the gateway over PSTN the music just gets alluded and then stops. The debug messages are not really helping. Is there a way how to figure this out? Oddly the transfer_ringback music is working in both ways vars.xml <X-PRE-PROCESS cmd="set" data="hold_music=$${sounds_dir}/music/output.mp3"/> <X-PRE-PROCESS cmd="set" data="transfer_ringback=$${sounds_dir}/music/output.mp3"/> dialplan/default.xml <action application="bridge_export" data="hold_music=$${sounds_dir}/music/output.mp3"/> Thank you

1 0

Re: [Freeswitch-users] Random Freeswitch Crash
by Jai Rangi 24 Apr '15

24 Apr '15

I see some replies, on archive, but not getting emails. Checked my spam also. Reply yo my own post, apology if this creates a new thread. I am using 1.4.18,. This is the first thing I did. Update from 1.4.11 Anthony suggest latest master branch, should I update to 1.5.1. I did not go for that as it was not recommended. I cant not reproduce the issue, if happens by itself and I have no idea. I will try to get as much information I can from this list https://freeswitch.org/confluence/display/FREESWITCH/Reporting+Bugs+to+JIRA I dont get any core dump, so I cant get backtrace. Do I have to enable something to get the code dump. I have this enabled in switch.conf.xml <param name="dump-cores" value="yes"/> On Fri, Apr 24, 2015 at 2:25 PM, Jai Rangi <jprangi(a)gmail.com> wrote: > FS Server has been running fine for last 5 months, suddenly since > yesterday it started crashing every few hours. Checked the log files and > did not see any error message. > > I made few changes recently: > > Enabled Shared line in sip_profile/internal > > <param name="presence-probe-on-register" value="true"/> > <param name="manage-shared-appearance" value="true"/> > > Using a LUA script for group call, change the originate to enterprise > originate. > > From > bridge(user/101@domainname,user/102@domainname) > > To > > bridge(<all_threads=true>user/101@domainname:_:user/102@domainname) > > The reason I did this, was that, if shared line is registered on more > than one device, we want all the devices to ring and other people should be > able to take call by just pressing the line numbers. > > Changes the debug to level to 10 and still no information in the log file. > No core dump was generated for me to share or look at. > > FS is running a server with decent specs. Dual CPU, Quad Core, 48 GB Ram. > SSD Hard drive. > > Wondering if anyone else had the smiler issue and if I can get a hint > where I can look for more hints on why FS dies all of a sudden. > > Thank you, > -Jai > >

1 0

Random Freeswitch Crash
by Jai Rangi 24 Apr '15

24 Apr '15

FS Server has been running fine for last 5 months, suddenly since yesterday it started crashing every few hours. Checked the log files and did not see any error message. I made few changes recently: Enabled Shared line in sip_profile/internal <param name="presence-probe-on-register" value="true"/> <param name="manage-shared-appearance" value="true"/> Using a LUA script for group call, change the originate to enterprise originate. From bridge(user/101@domainname,user/102@domainname) To bridge(<all_threads=true>user/101@domainname:_:user/102@domainname) The reason I did this, was that, if shared line is registered on more than one device, we want all the devices to ring and other people should be able to take call by just pressing the line numbers. Changes the debug to level to 10 and still no information in the log file. No core dump was generated for me to share or look at. FS is running a server with decent specs. Dual CPU, Quad Core, 48 GB Ram. SSD Hard drive. Wondering if anyone else had the smiler issue and if I can get a hint where I can look for more hints on why FS dies all of a sudden. Thank you, -Jai

5 4

Suspend RTP Transmission Until RTP Has Been Received From Remote Party
by JP 24 Apr '15

24 Apr '15

I've observed that FreeSWITCH will initially transmit RTP to the remote party's private IP address until it has received at least 10 packets, at which time it will start sending to the remote party's NATed address. Is there some way to suspend the transmission of RTP altogether until at least one packet has been received from the remote party? It would be ideal if this could be controlled on a per call and/or per SIP profile basis. Thanks,

2 1