VoIP Mailing List Archives

[gservat at gmail.com]

Hi,

Nice work on mod_fax! I just tried sending myself a couple of faxes and they were received successfully. I even tried using tone_detect which correctly detected the fax machine and fired off rxfax.

I wanted to report back on a couple of issues:

1) Even though the spool dir is set to /tmp/, I called up rxfax with data="rxfax.tiff" and it saved it in /. Shouldn't it save it in the spool dir?

2) After receiving the fax, the channel is never hanged up. The tone_detect app even detects the busy tone (which calls the hangup application when it detects it) but it just sits there for a long time until I manually uuid_kill it. Log says:

2008-11-17 11:59:08 [DEBUG] switch_core_session.c:489 switch_core_session_perform_receive_message() Send signal OpenZAP/1:1/1 [BREAK]
2008-11-17 12:00:20 [DEBUG] mod_fax.c:163 phase_e_handler() ==============================================================================
2008-11-17 12:00:20 [DEBUG] mod_fax.c:170 phase_e_handler() Fax successfully received.
2008-11-17 12:00:20 [DEBUG] mod_fax.c:181 phase_e_handler() Remote station id:
2008-11-17 12:00:20 [DEBUG] mod_fax.c:182 phase_e_handler() Local station id: Home
2008-11-17 12:00:20 [DEBUG] mod_fax.c:183 phase_e_handler() Pages transferred: 1
2008-11-17 12:00:20 [DEBUG] mod_fax.c:184 phase_e_handler() Total fax pages: 1
2008-11-17 12:00:20 [DEBUG] mod_fax.c:185 phase_e_handler() Image resolution: 8031x3850
2008-11-17 12:00:20 [DEBUG] mod_fax.c:186 phase_e_handler() Transfer Rate: 9600
2008-11-17 12:00:20 [DEBUG] mod_fax.c:188 phase_e_handler() ECM status off
2008-11-17 12:00:20 [DEBUG] mod_fax.c:189 phase_e_handler() remote country:
2008-11-17 12:00:20 [DEBUG] mod_fax.c:190 phase_e_handler() remote vendor:
2008-11-17 12:00:20 [DEBUG] mod_fax.c:191 phase_e_handler() remote model:
2008-11-17 12:00:20 [DEBUG] mod_fax.c:193 phase_e_handler() ==============================================================================
2008-11-17 12:00:23 [DEBUG] switch_ivr_async.c:1228 tone_detect_callback() TONE busy DETECTED
2008-11-17 12:00:23 [DEBUG] switch_core_session.c:667 switch_core_session_queue_private_event() Send signal OpenZAP/1:1/1 [BREAK]

... time goes by ... show channels returns:

FreeSWITCH>show channels
uuid,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,dialplan,context,read_codec,read_rate,write_codec,write_rate
da211ab0-b4af-11dd-9b26-492b0027ea62,2008-11-17 11:58:46,1226930326,OpenZAP/1:1/1,CS_EXECUTE,OpenZAP,52174195,,inbound_fax,rxfax,rxfax.tiff,XML,internal,PCMU,8000,PCMU,8000

1 total.

... until I finally call:

FreeSWITCH>uuid_kill da211ab0-b4af-11dd-9b26-492b0027ea62
+OK

In the dialplan, right after calling rxfax I call the hangup application.

Thanks to all involved for making FS, mod_fax, spandsp, etc!

Any help on the above would be greatly appreciated.
- Gonzalo

[gservat at gmail.com]

Good old fashioned "bump" mailing-list style I'm mainly concerned with 2) .. any ideas as to why the channel never gets hanged up? I had a look at the mod_fax.c code and it doesn't hang up the channel once a fax transmission ends so it should return to the dialplan .. right? The next application to execute should be "hangup" but it never does.

Thanks

On Mon, Nov 17, 2008 at 12:22 PM, Gonzalo Servat <gservat@gmail.com (gservat@gmail.com)> wrote:

[anthony.minessale at g...]

attach with gdb or get a gcore of the process and do
thread apply all bt and post the output to
http://pastebin.freeswitch.org (user and pass are in the auth dialog)


On Wed, Nov 19, 2008 at 7:10 AM, Gonzalo Servat <gservat@gmail.com (gservat@gmail.com)> wrote:

[gservat at gmail.com]

Hi Anthony,

I started up the FS process, sent myself a fax which was successfully received and ran:

gdb --batch --command=fs_debug.cmd --pid=`cat /opt/freeswitch/log/freeswitch.pid` /opt/freeswitch/bin/freeswitch >> fs_debug.txt

Where fs_debug.cmd is:

bt
bt full
thread apply all bt
thread apply all bt full

I hope this is the right process to get you something useful for debugging purposes. I've attached the fs_debug.txt file.

Something caught my eye when I killed the channel manually (the "Cannot write frame" bit):

FreeSWITCH>uuid_kill 1a865592-b80d-11dd-9123-ed78da2001e7
+OK

2008-11-21 18:49:20 [NOTICE] mod_commands.c:1045 kill_function() Hangup OpenZAP/1:1/1 [CS_EXECUTE] [NORMAL_CLEARING]
2008-11-21 18:49:20 [DEBUG] switch_channel.c:1440 switch_channel_perform_hangup() Send signal OpenZAP/1:1/1 [KILL]
2008-11-21 18:49:20 [DEBUG] switch_core_session.c:805 switch_core_session_signal_state_change() Send signal OpenZAP/1:1/1 [BREAK]
2008-11-21 18:49:20 [ERR] mod_fax.c:659 process_fax() Cannot write frame [datalen: 320, samples: 160]
2008-11-21 18:49:20 [DEBUG] switch_core_state_machine.c:446 switch_core_session_run() (OpenZAP/1:1/1) State EXECUTE going to sleep
2008-11-21 18:49:20 [DEBUG] switch_core_state_machine.c:374 switch_core_session_run() (OpenZAP/1:1/1) Running State Change CS_HANGUP
2008-11-21 18:49:20 [DEBUG] switch_core_state_machine.c:404 switch_core_session_run() (OpenZAP/1:1/1) State HANGUP
2008-11-21 18:49:20 [DEBUG] mod_openzap.c:429 channel_on_hangup() Changing state on 1:1 from UP to HANGUP
2008-11-21 18:49:20 [DEBUG] mod_openzap.c:472 channel_on_hangup() OpenZAP/1:1/1 CHANNEL HANGUP
2008-11-21 18:49:20 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() OpenZAP/1:1/1 Standard HANGUP, cause: NORMAL_CLEARING
2008-11-21 18:49:20 [DEBUG] switch_core_state_machine.c:404 switch_core_session_run() (OpenZAP/1:1/1) State HANGUP going to sleep
2008-11-21 18:49:20 [DEBUG] switch_core_media_bug.c:313 switch_core_media_bug_remove_all() Removing BUG from OpenZAP/1:1/1
2008-11-21 18:49:20 [DEBUG] switch_core_session.c:937 switch_core_session_thread() Session 1 (OpenZAP/1:1/1) Locked, Waiting on external entities
2008-11-21 18:49:20 [NOTICE] switch_core_session.c:955 switch_core_session_thread() Session 1 (OpenZAP/1:1/1) Ended
2008-11-21 18:49:20 [NOTICE] switch_core_session.c:957 switch_core_session_thread() Close Channel OpenZAP/1:1/1 [CS_HANGUP]
2008-11-21 18:49:20 [DEBUG] ozmod_analog.c:410 zap_analog_channel_run() Executing state handler on 1:1 for HANGUP
2008-11-21 18:49:20 [DEBUG] ozmod_analog.c:351 zap_analog_channel_run() Changing state on 1:1 from HANGUP to DOWN
2008-11-21 18:49:21 [DEBUG] ozmod_analog.c:410 zap_analog_channel_run() Executing state handler on 1:1 for DOWN
2008-11-21 18:49:21 [DEBUG] mod_openzap.c:1153 on_fxo_signal() got FXO sig 1:1 [STOP]
2008-11-21 18:49:21 [DEBUG] zap_io.c:1123 zap_channel_done() channel done 1:1
2008-11-21 18:49:21 [DEBUG] ozmod_analog.c:726 zap_analog_channel_run() ANALOG CHANNEL 1:1 thread ended.


On Wed, Nov 19, 2008 at 11:52 AM, Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)> wrote:

[anthony.minessale at g...]

looks like nothing tries to hangup the call when its done.

I added a call to hangup in the code,
update and try again please.


On Fri, Nov 21, 2008 at 2:59 PM, Gonzalo Servat <gservat@gmail.com (gservat@gmail.com)> wrote: