next »

[mcrane]

It looks like I ran the following too early in the install process. You can fix that by running the following from the pfSense GUI -> Diagnostics -> Command. Then run save the fax extension again and it create the remaining folder structure. I have committed this change so the install should work now. So your other choice is simply to upgrade to the latest version. Thanks for reporting it.

   if (!is_dir('/usr/local/freeswitch/storage/fax/')) {
      exec("mkdir /usr/local/freeswitch/storage/fax/");
   }

   if (!is_dir('/usr/local/freeswitch/storage/fax/receive/')) {
      exec("mkdir /usr/local/freeswitch/storage/fax/receive/");
   }

[clarknova]

My wife and I each had a conversation today where latency became quite high, probably 3-4 seconds on my call. The call length was recorded at 528 seconds and my wife's at 672. That's with the jitterbuffer set to 20 ms, but apparently not saving every call.

db

edit: I put this to the freeswitch-users mailing list and it was suggested to try
<action application="set" data="rtp_autoflush=true" />

[mcrane]

I put this to the freeswitch-users mailing list and it was suggested to try
<action application="set" data="rtp_autoflush=true" />

Sounds promising. I will add it to my system.

Also have talked to people that are using an older version of the FreeSWITCH package and they don't seem to have the issue. I will do additional testing on those systems to confirm. 

I'm also working with unixdawg who is working on a FreeBSD FreeSWITCH port and will be using it to create a new build of FreeSWITCH. When that is ready will do some more testing to see if it is affected.

Best Regards, Mark.

[mcrane]

FreeSWITCH package new minor version

clean up blank recordings,
add dialplan default.xml,
add dialplan public.xml,
adjust wording on setup,
and extension pages,
create lan profile directory if it doesn't exist,
status tabadd rescan and restart

I'm working on a new build of FreeSWITCH that will be ready on Monday or Tuesday.

[librarymark]

On the features tab, where every other feature has the word 'open', the DISA section has nothing. Should something show up when DISA is enabled? Also - when I upgraded to the latest packgage, I had 2 DISA entries in the dialplan.

And - when I click on the pfSense logo in the upper right-hand corner to go back to index page, I get a 404 instead. Looks like the freeswitch settings tab is the only page that works right in that respect.

[mcrane]

On the features tab, where every other feature has the word 'open', the DISA section has nothing. Should something show up when DISA is enabled?

No, There is nothing to configure in the GUI other than setting the admin pin number on the status page as described in the DISA description that are there on the page. Set the admin password and then call the DISA extension.

Also - when I upgraded to the latest packgage, I had 2 DISA entries in the dialplan.

This is a benign bug that doesn't cause any harm. Simply remove the duplicate. I will put that on my to do list to get it fixed.

And - when I click on the pfSense logo in the upper right-hand corner to go back to index page, I get a 404 instead. Looks like the freeswitch settings tab is the only page that works right in that respect.

This is a pfSense issue caused by wrong method of handling path links. To fix this will likely require fixing the link path in the pfsense themes.

[mcrane]

New version FreeSWITCH 0.9.2.4 uses a new FreeSWITCH revision 13784.

1. Testing up to this time seems to indicate that latency problem may be resolved will be doing more testing tomorrow to confirm.
2. Repaired mod_fax that was broken in 0.9.2.3
3. Added a caller id name prefix to IVR (auto attendant) and the Hunt Groups. This make is possible to indicate where the call came from.

[clarknova]

Back in 0.9.1 land, <action application="set" data="rtp_autoflush=true" /> seems to have reduced latency on long calls, but I think it's still there to a lesser degree. Hopefully 0.9.2.4 makes this a moot point, looking forward to trying it out.

db

[mrguitar]

Upgraded to 9.2.4 and it looks like the SIP profiles can't start.

This is what I'm getting under the status page:

Warning: opendir(/usr/local/freeswitch/conf/sip_profiles): failed to open dir: No such file or directory in /usr/local/pkg/freeswitch.inc on line 301 Warning: Invalid argument supplied for foreach() in /usr/local/www/packages/freeswitch/freeswitch_status.php on line 184 status

I've only had time to try restarting freeswitch and restore my backup. - not very in-depth. sorry.

[mcrane]

Back in 0.9.1 land, <action application="set" data="rtp_autoflush=true" /> seems to have reduced latency on long calls, but I think it's still there to a lesser degree. Hopefully 0.9.2.4 makes this a moot point, looking forward to trying it out.

Agreed rtp_autoflush=true helped to some degree on 0.9.1. However 0.9.2.4 so far is working good and looks like it has resolved the latency issue.

Upgraded to 9.2.4 and it looks like the SIP profiles can't start.

I worked with mrguitar on IRC and found there was something wrong with his backup file. SIP profiles are backed up in the backup normally. This backup wasn't large enough to be the complete backup and did not include the sip profile.

[phdonnelly]

New version FreeSWITCH 0.9.2.4 uses a new FreeSWITCH revision 13784.

1. Testing up to this time seems to indicate that latency problem may be resolved will be doing more testing tomorrow to confirm.
2. Repaired mod_fax that was broken in 0.9.2.3
3. Added a caller id name prefix to IVR (auto attendant) and the Hunt Groups. This make is possible to indicate where the call came from.

I'm getting an immediate segfault attempting to recieve a fax in freeswitch with 0.9.2.4 running 1.2.3-RC2. It appears to be a library version issue with spandsp/mod_fax

Some troubleshooting follows:

# /usr/local/bin/gdb66 --args /usr/local/freeswitch/bin/freeswitch -c -waste
GNU gdb 6.6 [GDB v6.6 for FreeBSD]
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd7.2"...
(gdb) run

-----Freeswitch startup snipped----

2009-06-17 21:04:57.483533 [NOTICE] switch_channel.c:602 New Channel sofia/internal/1010@sip.od.donnellyclan.org [4548650a-a45b-de11-9aef-0017319ad0c8]
2009-06-17 21:04:57.498540 [INFO] mod_dialplan_xml.c:252 Processing Patrick H Donnelly->7100 in context default
2009-06-17 21:04:57.504619 [INFO] switch_core_session.c:1391 Sending early media
2009-06-17 21:04:57.514531 [INFO] mod_sofia.c:1493 Ring SDP:
v=0
o=FreeSWITCH 1245254783 1245254784 IN IP4 98.109.123.106
s=FreeSWITCH
c=IN IP4 98.109.123.106
t=0 0
m=audio 32314 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

2009-06-17 21:04:57.514531 [NOTICE] mod_sofia.c:1496 Pre-Answer sofia/internal/1010@sip.od.donnellyclan.org!
2009-06-17 21:04:57.555712 [NOTICE] mod_dptools.c:649 Channel [sofia/internal/1010@sip.od.donnellyclan.org] has been answered

Program received signal SIGSEGV, Segmentation fault.
fax_rx (s=0x29567018, amp=0x0, len=4096) at fax.c:252
252   fax.c: No such file or directory.
   in fax.c
(gdb) bt
#0  fax_rx (s=0x29567018, amp=0x0, len=4096) at fax.c:252
#1  0x28d50ce9 in process_fax (session=0x28e8f018, data=0x28603f00 "/usr/local/freeswitch/storage/fax/7100/inbox/1010-2009-06-17-21-04-59.tif", app_mode=FUNCTION_RX) at mod_fax.c:644
#2  0x28d51110 in spanfax_rx_function (session=0x28e8f018, data=0x28603f00 "/usr/local/freeswitch/storage/fax/7100/inbox/1010-2009-06-17-21-04-59.tif") at mod_fax.c:776
#3  0x280d741c in switch_core_session_exec (session=0x28e8f018, application_interface=0x28f84128, arg=0x294f5070 "/usr/local/freeswitch/storage/fax/7100/inbox/${last_fax}.tif")
    at src/switch_core_session.c:1475
#4  0x280d7939 in switch_core_session_execute_application (session=0x28e8f018, app=0x294f5068 "rxfax", arg=0x294f5070 "/usr/local/freeswitch/storage/fax/7100/inbox/${last_fax}.tif")
    at src/switch_core_session.c:1397
#5  0x280dd9c5 in switch_core_session_run (session=0x28e8f018) at src/switch_core_state_machine.c:166
#6  0x280d9445 in switch_core_session_thread (thread=0x28f7ab40, obj=0x28e8f018) at src/switch_core_session.c:1065
#7  0x2814bac6 in dummy_worker (opaque=0x28f7ab40) at threadproc/unix/thread.c:138
#8  0x28223741 in ?? () from /lib/libthr.so.3
#9  0x28f7ab40 in ?? ()
#10 0x00000000 in ?? ()

---------------------------

From the backtrace it's apparently dieing in fax_rx of fax.c in the spandsp module but it really shouldn't be. Line 252 is marked w/ an * here:

Code:

SPAN_DECLARE(int) fax_rx(fax_state_t *s, int16_t *amp, int len)
{
    int i;

#if defined(LOG_FAX_AUDIO)
    if (s->modems.audio_rx_log >= 0)
        write(s->modems.audio_rx_log, amp, len*sizeof(int16_t));
#endif
    for (i = 0;  i < len;  i++)
        amp[i] = dc_restore(&s->modems.dc_restore, amp[i]);
*    s->modems.rx_handler(s->modems.rx_user_data, amp, len);
    t30_timer_update(&s->t30, len);
    return 0;
}

From what I can tell, all the objects being referenced are valid, so we shouldn't be getting a SIGSEGV
--------------
(gdb) print s
$1 = (fax_state_t *) 0x29567018
(gdb) print s->modems
$2 = {use_tep = 685042368, transmit_on_idle = 1, hdlc_tx = {crc_bytes = 2, underflow_handler = 0x28d6cc50 <hdlc_underflow_handler>, user_data = 0x29567018, inter_frame_flags = 2, progressive = 0,
-----SNIP large amount of variables-----
(gdb) print s->modems.rx_user_data
$3 = (void *) 0x29578138
(gdb) print s->modems.rx_handler 
$4 = (span_rx_handler_t *) 0x28d6d920 <fsk_rx>

-------
However, Here's where it gets somewhat interesting: s->modems.rx_handler is a function pointer for the current modem state; in this case, the function it's pointing to, fsk_rx, is defined thus:

SPAN_DECLARE_NONSTD(int) fsk_rx(fsk_rx_state_t *s, const int16_t *amp, int len)

Note that rx_user_data above is a void pointer, being implicitly cast to fsk_rx_state_t, casting it ourselves in GDB yields:
--------
print (fsk_rx_state_t)s->modems.rx_user_data
$5 = {baud_rate = 693641528, sync_mode = 685224400, put_bit = 0x29583cb0, put_bit_user_data = 0x0, status_handler = 0, status_user_data = 0x0, carrier_on_power = 300, carrier_off_power = 1, power = {shift = 0,
    reading = 0}, last_sample = 0, signal_present = 0, phase_rate = {0, 0}, phase_acc = {0, 0}, correlation_span = 0, window = {{{re = 0, im = 0}, {re = 8000, im = 0}, {re = 0, im = 0}, {re = 685655762,
        im = 685200768}, {re = 0, im = 0}, {re = 0, im = 0}, {re = 0, im = 0}, {re = 0, im = 685042368}, {re = 0, im = 693100568}, {re = 693081792, im = 692880944}, {re = 693650976, im = 672421184}, {
        re = 672422848, im = 693100568}, {re = 693081856, im = 693650984}, {re = 693651000, im = 672421184}, {re = 672422848, im = 0}, {re = 0, im = 0} <repeats 113 times>}, {{re = 0,
        im = 0} <repeats 128 times>}}, dot = {{re = 0, im = 0}, {re = 0, im = 0}}, buf_ptr = 0, baud_inc = 0, baud_pll = 0, lastbit = 0, scaling_shift = 0}
-----
Aside from the odd baud rate, the data appears to be superficially valid for a first run, dot products are zeroed, last sample populated with data, etc, HOWEVER, opening fsk.h from rev. 13784 of freeswitch shows fsk_rx_state_t with different fields: baud_rate, framing mode, ... The 0.5 tarball from the spandsp site shows the same old variable names: baud_rate, sync_mode, etc. So apparently there's a disconnect somewhere. As a precaution I wiped all libspandsp files on my box and re-installed the pfsense base image and freeswitch, but the problem seems to persist.

Do you have a version of freeswitch/spandsp compiled with full debugging symbols I could D/L to see if I can get some more info that way?

[mcrane]

FreeSWITCH package has been updated to version 0.9.3.

1. New version fixes problems with mod_fax
2. Strips invalid common characters from caller id number on the extensions.
3. New Extension option keep the local voicemail file after sending the email.
4. Add ring back option to hunt groups so it is possible to choose between music on hold or ring tone.

[joejohn]

Hey guys, first off I really appreciate all the work that has went into this and I like freeswitch a lot... but unfortunately it's looking like I am going to be forced to give up on freeswitch.  In a nutshell, our business and clients have had enough with all the surprises that are cropping up with the pbx... so basically, I'm coming here seeking some general advice.

I running the 0.9.3 freeswitch package on pfsense.

Over the past couple months our small company decided to give freeswitch a try because we were already using pfsense and also we had experienced some asterisk NAT issues in the past that we wanted to completely eliminate.  So the freeswitch pfsense package sounded like a great idea.... however now at this point it's looking like I will be unable to use freeswitch.  I am just having problem after problem after problem for the past month and a half... seems like something new crops up everyday now.

So well, anyway, my point is that I just wanted to check with the users here to see if my situation sounds common or if possibly maybe this is just meant for test usage or a sandbox and not really for a business.

Don't get me wrong I fully appreciate the work and time that has been put into this and love the product and a sincere thanks to all involved... but I'm just trying to get a grip on reality here and see what others think about my situation.

[clarknova]

My experience has been that when I have an issue it's usually because I've misconfigured something. Occasionally I can also blame the pfsense-freeswitch GUI for being vague or incomplete. I have yet to encounter a single issue stemming from the freeswitch engine itself.

That said, I have nothing but praise for mcrane and the team that supports him. Yeah, the GUI is incomplete and imperfect, but consider that A, it's the best if not only freeswitch GUI in existence, B, it's developing rapidly with a new release what, every week or so, and C, mcrane et al work hard to answer questions on the forum and in IRC.

In summary, yeah I've had issues, and yeah, I can understand if somebody feels the experience isn't smooth enough for their needs. Nevertheless, I feel strongly that freeswitch itself is production-ready, and the pfsense-freeswitch package is on course to be as well.

Sorry to hear it didn't work out for you this time.

db

[mcrane]

So well, anyway, my point is that I just wanted to check with the users here to see if my situation sounds common or if possibly maybe this is just meant for test usage or a sandbox and not really for a business.

You need to explain your situation in order to get help either on the forum or on IRC. Your posting here only explains your frustration with no details.

I don't believe I have ever chatted with you on IRC unless you have a different nickname you use there.