- FreeSWITCH-users - FreeSWITCH Mailing Lists

Re: [Freeswitch-users] FreeSWITCH-users Digest, Vol 103, Issue 177
by Ahmed Habiba 15 Jan '15

15 Jan '15

Thank you really David, Here is my point, the sip-trace in the first mail shows that, the call comes to public context mainly through port 5080, and however the originator IP was not defined in my ACL list Freeswitch continue to process the call for some reason. even if it come to 5060, I was expecting some request for digest authentication, which is not shown in the log. From: David Villasmil Govea <david.villasmil(a)gmail.com <mailto:david.villasmil@gmail.com>> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 8:30:35 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue Authorization is done if you configure your sip profile to do it. By default 5060 (internal) requires authentication, 5080 (external) doesn't but it does use the ACL to allow or not calls. On Jan 14, 2015 6:22 PM, "Ahmed Habiba" <ahabiba(a)gmail.com <mailto:ahabiba@gmail.com>> wrote: Thanks Brian, What I got from the below link that unless having a record like the below in acl.conf.xml, Digest Authentication(i.e. username/password) will be required, please correct me. https://wiki.freeswitch.org/wiki/Connect_Two_FreeSWITCH_Boxes <https://wiki.freeswitch.org/wiki/Connect_Two_FreeSWITCH_Boxes> <node type="allow" cidr="10.10.0.1/32 <http://10.10.0.1/32>"/> From: Brian West <brian(a)freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:49:32 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue Unless you've changed the configs its not setup to do that out of the box. On Wed, Jan 14, 2015 at 10:39 AM, Ahmed Habiba <ahabiba(a)gmail.com <mailto:ahabiba@gmail.com>> wrote: Dear Brian, Thank you really for your feedback, what you mentioned is correct, however I understand that any call to comes from external system to public context to processed , the external system IP shall be allowed via ACL, accordingly we shouldn't expect any traffic to processed from a server/IP that is not defined in the ACL, am I correct? Thanks, Ahmed Habiba. From: Brian West <brian(a)freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:29:28 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue You have some learning to do about VoIP and various security models. See comments inline. On Wed, Jan 14, 2015 at 10:08 AM, Ahmed Habiba <ahabiba(a)gmail.com <mailto:ahabiba@gmail.com>> wrote: Dears, Kindly I noticed a very strange behaviour on Freeswitch that may allow non authorised users to make call through the system below is the log and my notice highlighted, you help will be appreciated. 1-Below is a request coming from not authored IP. 2-However the originating IP is “142.54.179.218” the from is as below as if it is from the same server: The IP was 142.54.179.218... thats the real IP we received the request from. freeswitch@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099: ------------------------------------------------------------------------ INVITE <> <> <>sip:9009972599796504@177.31.245.177:5080 <sip:9009972599796504@177.31.245.177:5080> SIP/2.0 To: 9009972599796504< <> <> <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> From: 1000< <> <> <>sip:1000@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Contact: < <> <> <>sip:1000@142.54.179.218:5070 <sip:1000@142.54.179.218:5070>> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE User-Agent: sipcli/v1.8 Content-Type: application/sdp Content-Length: 285 v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv 3-Accordingly Freeswitch start to deal with the call normally As it should, Its hitting the external profile which doesn't have authentication on it. ------------------------------------------------------------------------ send 333 bytes to udp/[142.54.179.218]:5070 at 16:41:34.211442: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport=5070 From: 1000< <> <> <>sip:1000@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 To: 9009972599796504< <> <> <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Content-Length: 0 ———————————————————————————————————— 4-as we can see below Freeswitch consider the call coming from my server IP not from the remote IP(My server IP = 177.31.245.177) No thats false, This is just a channel named thats formed from various bits of data, Its meaningless data and can be set, overridden or changed. This has no bearing on what freeswitch thinks. Most likely its using the host element from the From header. 2015-01-14 16:41:34.203196 [NOTICE] switch_channel.c:1055 New Channel sofia/external/1000(a)177.31.245.177 <mailto:1000@177.31.245.177> [d1879400-9c03-11e4-8cd6-2f1eb174d7b4] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> receiving invite from 142.54.179.218:5070 <http://142.54.179.218:5070/> version: 1.4.13 git b942d0f 2014-11-03 19:53:00Z 64bit 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6606 Channel sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> entering state [received][100] 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6616 Remote SDP: v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6868 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State Change CS_NEW -> CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State Change CS_INIT -> CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT going to sleep 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Callstate Change DOWN -> RINGING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:528 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard ROUTING This is someone from outside calling in to your system, the public context is a sandbox to allow you to isolate and route non-authenticated traffic to your internal contexts via the transfer app, per the vanilla config examples. This is also whey you need to understand how to secure FreeSWITCH. 2015-01-14 16:41:34.203196 [INFO] mod_dialplan_xml.c:558 Processing 1000 <1000>->9009972599796504 in context public _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> -- Brian West brian(a)freeswitch.org <mailto:brian@freeswitch.org> Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> T:+19184209001 <tel:%2B19184209001> | F:+19184209002 <tel:%2B19184209002> | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | <> <>Skype: <skype:briankwest> <> <>briankwest <skype:briankwest>

3 3

Video MCU
by Kumar, Sharath 14 Jan '15

14 Jan '15

All, Does anyone knows if the Freeswitch 1.6 beta will support an video MCU ? Any timelines? thank you, Shaks.

2 1

FreeSWITCH Week in Review (Master Branch) January 4th-10th
by Ken Rice 14 Jan '15

14 Jan '15

New Post on freeswitch.org from kathleen check it out at http://ift.tt/1C1TXya FreeSWITCH Week in Review (Master Branch) January 4th-10th Hello, again. This week in the FreeSWITCH master branch we had 36 commits. Most of the features for this week involve mod_verto and include: fixes for recent firefox changes in mod_verto, work toward browser compatibility in mod_verto, some stuff to verto for introp, and some of the other commits worked toward updates for js, tweaking cdquality conference defaults, and adding utils. New features that were added: 8251218 Tweak cdquality conference defaults 66c425c Add utils 94bb460 Fixes for recent firefox changes in mod_verto 41bfc18 Add some stuff to verto for introp 9ca115c More work toward browser compatibility in mod_verto b79a7e1 Vid screen share placeholder –args –enable-usermedia-screen-capturing –usermedia-screen-capturing b170e9e Update minified js 6c1bc0e Sync ws code Improvements to packaging: 2a05f8c Drop limit on stack size via systemd Improvements in cross platform build supports: 7c0c3ab Sofia rebuild 19a0a0f Sofia rebuild The following bugs were squashed: 4512dbc Fix multi screen bash history issues ece5cd5 FS-7088 #resolve Set flag to enable core dump from non-root users. [Jira: http://ift.tt/1C1TVXa] f48ec61 FS-7132 Resolve jsock hash overwrite issue in mod_verto [Jira: http://ift.tt/1u7zZf1] 165f542 FS-7137 Set sip_to_tag on ringing indication for inbound channels in mod_sofia 85b8631 FS-7136 Add conference member data to floor event in mod_conference 51f2442 FS-7122 Resolve an automake warning about subdirs on latest automake 16f7177 FS-7122 Resolve an automake warning about subdirs on latest automake 6afc2b5 FS-6688 Fix resubscribe through proxy with record route when the resub does not have a record route and the route has uri params [Jira: http://ift.tt/1yzQEuo] d199060 FS-7036 Fixed race condition [Jira: http://ift.tt/1u7zYrv] a2b5356 FS-7131 Fix for a segfault [Jira: http://ift.tt/1u7zZf5] d82611a FS-7142 Fix build of freetdm on CentOS c460c00 FS-7134 Improved Zoiper subscribes [Jira: http://ift.tt/1C1TWdy]

1 0

Detecting originate failures from dialplan
by Oleg Stolyar 14 Jan '15

14 Jan '15

Hi guys, I have a line like this in my dialplan: <action inline="true" application="set" data="api_result=${originate(sofia/external/<phone number>@2.3.4.5:5060 <extension> XML <profile> How can I know if the originate failed? For example the number is unreacheable or invalid or the trunk is down. In this case the <extension> will not be executed. It seems that my dialplan continues to execute even if originate failed but is there something I can do to check for that?

2 3

Re: [Freeswitch-users] Security Issue
by Ahmed Habiba 14 Jan '15

14 Jan '15

Thanks Brian, What I got from the below link that unless having a record like the below in acl.conf.xml, Digest Authentication(i.e. username/password) will be required, please correct me. https://wiki.freeswitch.org/wiki/Connect_Two_FreeSWITCH_Boxes <https://wiki.freeswitch.org/wiki/Connect_Two_FreeSWITCH_Boxes> <node type="allow" cidr="10.10.0.1/32"/> From: Brian West <brian(a)freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:49:32 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue Unless you've changed the configs its not setup to do that out of the box. On Wed, Jan 14, 2015 at 10:39 AM, Ahmed Habiba <ahabiba(a)gmail.com <mailto:ahabiba@gmail.com>> wrote: Dear Brian, Thank you really for your feedback, what you mentioned is correct, however I understand that any call to comes from external system to public context to processed , the external system IP shall be allowed via ACL, accordingly we shouldn't expect any traffic to processed from a server/IP that is not defined in the ACL, am I correct? Thanks, Ahmed Habiba. From: Brian West <brian(a)freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:29:28 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue You have some learning to do about VoIP and various security models. See comments inline. On Wed, Jan 14, 2015 at 10:08 AM, Ahmed Habiba <ahabiba(a)gmail.com <mailto:ahabiba@gmail.com>> wrote: Dears, Kindly I noticed a very strange behaviour on Freeswitch that may allow non authorised users to make call through the system below is the log and my notice highlighted, you help will be appreciated. 1-Below is a request coming from not authored IP. 2-However the originating IP is “142.54.179.218” the from is as below as if it is from the same server: The IP was 142.54.179.218... thats the real IP we received the request from. freeswitch@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099: ------------------------------------------------------------------------ INVITE <> <>sip:9009972599796504@177.31.245.177:5080 <sip:9009972599796504@177.31.245.177:5080> SIP/2.0 To: 9009972599796504< <> <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> From: 1000< <> <>sip:1000@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Contact: < <> <>sip:1000@142.54.179.218:5070 <sip:1000@142.54.179.218:5070>> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE User-Agent: sipcli/v1.8 Content-Type: application/sdp Content-Length: 285 v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv 3-Accordingly Freeswitch start to deal with the call normally As it should, Its hitting the external profile which doesn't have authentication on it. ------------------------------------------------------------------------ send 333 bytes to udp/[142.54.179.218]:5070 at 16:41:34.211442: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport=5070 From: 1000< <> <>sip:1000@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 To: 9009972599796504< <> <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Content-Length: 0 ———————————————————————————————————— 4-as we can see below Freeswitch consider the call coming from my server IP not from the remote IP(My server IP = 177.31.245.177) No thats false, This is just a channel named thats formed from various bits of data, Its meaningless data and can be set, overridden or changed. This has no bearing on what freeswitch thinks. Most likely its using the host element from the From header. 2015-01-14 16:41:34.203196 [NOTICE] switch_channel.c:1055 New Channel sofia/external/1000(a)177.31.245.177 <mailto:1000@177.31.245.177> [d1879400-9c03-11e4-8cd6-2f1eb174d7b4] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> receiving invite from 142.54.179.218:5070 <http://142.54.179.218:5070/> version: 1.4.13 git b942d0f 2014-11-03 19:53:00Z 64bit 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6606 Channel sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> entering state [received][100] 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6616 Remote SDP: v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6868 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State Change CS_NEW -> CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State Change CS_INIT -> CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT going to sleep 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Callstate Change DOWN -> RINGING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:528 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard ROUTING This is someone from outside calling in to your system, the public context is a sandbox to allow you to isolate and route non-authenticated traffic to your internal contexts via the transfer app, per the vanilla config examples. This is also whey you need to understand how to secure FreeSWITCH. 2015-01-14 16:41:34.203196 [INFO] mod_dialplan_xml.c:558 Processing 1000 <1000>->9009972599796504 in context public _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> -- Brian West brian(a)freeswitch.org <mailto:brian@freeswitch.org> Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> T:+19184209001 <tel:%2B19184209001> | F:+19184209002 <tel:%2B19184209002> | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | <>Skype: <skype:briankwest> <>briankwest <skype:briankwest>

3 2

FreeSWITCH Launches New Platform on 10th Anniversary
by Ken Rice 14 Jan '15

14 Jan '15

New Post on freeswitch.org from anthm check it out at http://ift.tt/1IKASRe FreeSWITCH Launches New Platform on 10th Anniversary The first line of code in FreeSWITCH was drafted Spring of 2005, nearly a decade ago. 2015 marks the 10-year anniversary of the core code and the 9-year anniversary of the FreeSWITCH Public Community. Over the years, the core developers of the project have worked hard to provide top notch community support. FreeSWITCH Solutions, the consulting firm owned and operated by the core FreeSWITCH team, have been offering commercial support for many years for companies who take things to the next level and use FreeSWITCH to power their products. Today we are proud to announce the unveiling of FreeSWITCH.com and the FreeSWITCH Advantage™ platform and support. Built on top of Debian Linux, FreeSWITCH Advantage takes our proven support services and couples it with a reliable operating system distribution and the result is a uniform packaged system tuned specifically for running FreeSWITCH. New releases will be simple to apply and any changes to the other packages on the system that have an impact on FreeSWITCH will be applied and managed automatically. Customers will have the best environment possible in place to run their systems as well as the support they need to ensure they stay up and running. The FreeSWITCH Advantage provides critical early-access to releases to make sure any problems encountered are addressed ASAP. All of the code used with FreeSWITCH Advantage is taken straight from the project’s public git repository and packaged with testing and stability in mind so the community continues to benefit as a result. FreeSWITCH Solutions also continues to offer the most comprehensive consulting services available with the experience and knowledge to create almost anything imaginable that pertains to interfacing with FreeSWITCH.

1 0

Re: [Freeswitch-users] Mod LCR SQL sub-query for better routing
by DP . 14 Jan '15

14 Jan '15

Victor, I take back my initial response on this old email. We ran into a couple of cases with some carriers and multiple matching prefixes. After actually trying your sub query (modified for Mysql), it actually does return the true lowest rate from a carrier while importantly respecting the longest match per carrier. Unlike the reorder_by_rate function that does not respect the longest match per carrier. That function simply returns the lowest rate, period. So thanks! From: hi-tecc(a)hotmail.com To: freeswitch-users(a)lists.freeswitch.org Subject: RE: [Freeswitch-users] Mod LCR SQL sub-query for better routing Date: Mon, 16 Dec 2013 18:36:06 -0500 I agree. This definitely sounds like he simply needed the "reorder_by_rate" param. It will reorder the initial sql results strictly by rate: reorder_by_rate - Forces the LCR module to re-order the query strictly on rate basis. By default this is turned off, but enabling this will always prefer rate over anything else. Beware this may have an adverse effect! I initially had this turned on then quickly realized it would sometimes try to route ALL calls by the lowest rate found. Ex: flowroute lists all calls for the US with a default NPA of "1" at .0098. Now a user trying to call Jamaica with "1876" at a rate of 0.19 (or whatever) will get both flowroute rates returned. The reorder by rate will assume 0.0098 is a valid rate since it will now be the "cheapest" in the list and send the call along its way to flowroute, whom will now bill you at 0.19. Now if you have another carrier in your list with 1876 at 0.15 you can see why this would be a problem. In this case you will always want the longest matched NPANXX rate. Date: Fri, 13 Dec 2013 15:58:54 -0500 From: intralanman(a)freeswitch.org To: freeswitch-users(a)lists.freeswitch.org Subject: Re: [Freeswitch-users] Mod LCR SQL sub-query for better routing On 12/12/2013 02:42 PM, Victor Chukalovskiy wrote: Hello, For those interested, I added a piece to mod lcr wiki. It makes sorting / routing logic better than default logic: http://wiki.freeswitch.org/wiki/Mod_lcr#Custom_SQL_with_sub-query_-_for_rea… Why it helps: Rates rates can often be given both on per-NPA or per-NPANXX level depending on the carrier and on the NPA. Moreover, some carriers may have NPANXX rate lower than the corresponding NPA rate, while others will have it inverse. Neither simple ORDER BY rate, prefix; nor ORDER BY prefix, rate; give the truly cheapest route. The LCR logic should be two-step process to accommodate this. Cheers, -Victor Unless I misunderstand what you're saying, this is what the reorder_by_rate param does. You'll always want to pick the longest digit match per carrier. Then you probably want to grab the cheapest overall rate of the matches you got back. -Ray _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

3 2

Re: [Freeswitch-users] Security Issue
by Ahmed Habiba 14 Jan '15

14 Jan '15

Dear Brian, Thank you really for your feedback, what you mentioned is correct, however I understand that any call to comes from external system to public context to processed , the external system IP shall be allowed via ACL, accordingly we shouldn't expect any traffic to processed from a server/IP that is not defined in the ACL, am I correct? Thanks, Ahmed Habiba. From: Brian West <brian(a)freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:29:28 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue You have some learning to do about VoIP and various security models. See comments inline. On Wed, Jan 14, 2015 at 10:08 AM, Ahmed Habiba <ahabiba(a)gmail.com <mailto:ahabiba@gmail.com>> wrote: Dears, Kindly I noticed a very strange behaviour on Freeswitch that may allow non authorised users to make call through the system below is the log and my notice highlighted, you help will be appreciated. 1-Below is a request coming from not authored IP. 2-However the originating IP is “142.54.179.218” the from is as below as if it is from the same server: The IP was 142.54.179.218... thats the real IP we received the request from. freeswitch@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099: ------------------------------------------------------------------------ INVITE <>sip:9009972599796504@177.31.245.177:5080 <sip:9009972599796504@177.31.245.177:5080> SIP/2.0 To: 9009972599796504< <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> From: 1000< <>sip:1000@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Contact: < <>sip:1000@142.54.179.218:5070 <sip:1000@142.54.179.218:5070>> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE User-Agent: sipcli/v1.8 Content-Type: application/sdp Content-Length: 285 v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv 3-Accordingly Freeswitch start to deal with the call normally As it should, Its hitting the external profile which doesn't have authentication on it. ------------------------------------------------------------------------ send 333 bytes to udp/[142.54.179.218]:5070 at 16:41:34.211442: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport=5070 From: 1000< <>sip:1000@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 To: 9009972599796504< <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Content-Length: 0 ———————————————————————————————————— 4-as we can see below Freeswitch consider the call coming from my server IP not from the remote IP(My server IP = 177.31.245.177) No thats false, This is just a channel named thats formed from various bits of data, Its meaningless data and can be set, overridden or changed. This has no bearing on what freeswitch thinks. Most likely its using the host element from the From header. 2015-01-14 16:41:34.203196 [NOTICE] switch_channel.c:1055 New Channel sofia/external/1000(a)177.31.245.177 <mailto:1000@177.31.245.177> [d1879400-9c03-11e4-8cd6-2f1eb174d7b4] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> receiving invite from 142.54.179.218:5070 <http://142.54.179.218:5070/> version: 1.4.13 git b942d0f 2014-11-03 19:53:00Z 64bit 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6606 Channel sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> entering state [received][100] 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6616 Remote SDP: v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6868 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State Change CS_NEW -> CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State Change CS_INIT -> CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT going to sleep 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Callstate Change DOWN -> RINGING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:528 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard ROUTING This is someone from outside calling in to your system, the public context is a sandbox to allow you to isolate and route non-authenticated traffic to your internal contexts via the transfer app, per the vanilla config examples. This is also whey you need to understand how to secure FreeSWITCH. 2015-01-14 16:41:34.203196 [INFO] mod_dialplan_xml.c:558 Processing 1000 <1000>->9009972599796504 in context public _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> -- Brian West brian(a)freeswitch.org <mailto:brian@freeswitch.org> Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> T:+19184209001 <tel:%2B19184209001> | F:+19184209002 <tel:%2B19184209002> | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype: <skype:briankwest>briankwest <skype:briankwest>

2 1

Security Issue
by Ahmed Habiba 14 Jan '15

14 Jan '15

Dears, Kindly I noticed a very strange behaviour on Freeswitch that may allow non authorised users to make call through the system below is the log and my notice highlighted, you help will be appreciated. 1-Below is a request coming from not authored IP. 2-However the originating IP is “142.54.179.218” the from is as below as if it is from the same server: freeswitch@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099: ------------------------------------------------------------------------ INVITE sip:9009972599796504@177.31.245.177:5080 SIP/2.0 To: 9009972599796504<sip:9009972599796504@177.31.245.177> From: 1000<sip:1000@177.31.245.177>;tag=e8473b10 Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Contact: <sip:1000@142.54.179.218:5070> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE User-Agent: sipcli/v1.8 Content-Type: application/sdp Content-Length: 285 v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv 3-Accordingly Freeswitch start to deal with the call normally ------------------------------------------------------------------------ send 333 bytes to udp/[142.54.179.218]:5070 at 16:41:34.211442: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport=5070 From: 1000<sip:1000@177.31.245.177>;tag=e8473b10 To: 9009972599796504<sip:9009972599796504@177.31.245.177> Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Content-Length: 0 ———————————————————————————————————— 4-as we can see below Freeswitch consider the call coming from my server IP not from the remote IP(My server IP = 177.31.245.177) 2015-01-14 16:41:34.203196 [NOTICE] switch_channel.c:1055 New Channel sofia/external/1000(a)177.31.245.177 [d1879400-9c03-11e4-8cd6-2f1eb174d7b4] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000(a)177.31.245.177 receiving invite from 142.54.179.218:5070 version: 1.4.13 git b942d0f 2014-11-03 19:53:00Z 64bit 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6606 Channel sofia/external/1000(a)177.31.245.177 entering state [received][100] 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6616 Remote SDP: v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6868 (sofia/external/1000(a)177.31.245.177) State Change CS_NEW -> CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (sofia/external/1000(a)177.31.245.177) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177) Running State Change CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000(a)177.31.245.177 SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000(a)177.31.245.177 Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (sofia/external/1000(a)177.31.245.177) State Change CS_INIT -> CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177) State INIT going to sleep 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (sofia/external/1000(a)177.31.245.177) Callstate Change DOWN -> RINGING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:528 (sofia/external/1000(a)177.31.245.177) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000(a)177.31.245.177 SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000(a)177.31.245.177 Standard ROUTING 2015-01-14 16:41:34.203196 [INFO] mod_dialplan_xml.c:558 Processing 1000 <1000>->9009972599796504 in context public

2 1

Current FreeSWITCH licensing page?
by Craig Stevenson 14 Jan '15

14 Jan '15

I am trying to track down current FreeSWITCH licensing information. I found http://wiki.freeswitch.org/wiki/Licensing but that was last updated two years ago and is in the obsolete wiki. I suspect there are a few additional components added over the past few years. I'm sure it is there somewhere on the new site. But searching for "License" or "Licensing" on freeswtich.org page doesn't find it for me. Thanks, Craig

3 2