July 2010 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Not able to do outbound call
by ovvenkat 21 Jul '10

21 Jul '10

Hi to all, I am very new to this world. I am not able to do outbound call using Sangoma A101 card and freeSwitch. Here is the procedure I have followed *openzap.conf* [span wanpipe smg_prid] name => smg_prid trunk_type =>e1 b-channel => 1:1-15 d-chennel => 1:16 b-channel => 1:17-31 I have one span in *openzap.conf.xml* <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="0"/> </settings> <boot_spans> <span id="smg_prid"/> <param name="node" value="cpe"/> <param name="switch" value="ni1"> <param name="dialplan" value="XML"> <param name="context" value="default"> </span> <boot_spans> <analog_spans> </analog_spans> </configuration > </analog_spans> *My Dial plan is *added one extension in default.xml file <extension name="outgoing-pri"> <condition field="destination_number" expression="12345"> <action application="bridge" data="OpenZAP/smg_prid/a/<my number>@g1"/> </condition> </extension> When i trying to call "12345" I am getting following output in *fs_cli* , 2010-07-19 01:50:17.531933 [DEBUG] sofia.c:5992 IP 192.168.1.100 Rejected by acl "domains". Falling back to Digest auth. 2010-07-19 01:50:17.562934 [DEBUG] sofia.c:5992 IP 192.168.1.100 Rejected by acl "domains". Falling back to Digest auth. 2010-07-19 01:50:17.581933 [NOTICE] switch_channel.c:776 New Channel sofia/internal/1000(a)192.168.1.110 [36c842f2-8078-4ca0-a6e0-36f5d65f81f8] 2010-07-19 01:50:17.583936 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/1000(a)192.168.1.110) Running State Change CS_NEW 2010-07-19 01:50:17.583936 [DEBUG] switch_core_state_machine.c:320 (sofia/internal/1000(a)192.168.1.110) State NEW 2010-07-19 01:50:17.615937 [DEBUG] sofia.c:4310 Channel sofia/internal/ 1000(a)192.168.1.110 entering state [received][100] 2010-07-19 01:50:17.615937 [DEBUG] sofia.c:4321 Remote SDP: v=0 o=- 4 2 IN IP4 192.168.1.100 s=CounterPath X-Lite 3.0 c=IN IP4 192.168.1.100 t=0 0 m=audio 36422 RTP/AVP 107 0 8 101 a=rtpmap:107 BV32/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=alt:1 1 : hH//orIg hS6anlnf 192.168.1.100 36422 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [BV32:107:16000:20]/[G7221:115:32000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [BV32:107:16000:20]/[G7221:107:16000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [BV32:107:16000:20]/[G722:9:8000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [BV32:107:16000:20]/[PCMU:0:8000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [BV32:107:16000:20]/[PCMA:8:8000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [BV32:107:16000:20]/[GSM:3:8000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [PCMU:0:8000:20]/[G7221:115:32000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [PCMU:0:8000:20]/[G7221:107:16000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [PCMU:0:8000:20]/[G722:9:8000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3859 Audio Codec Compare [PCMU:0:8000:20]/[PCMU:0:8000:20] 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:2442 Set Codec sofia/internal/1000(a)192.168.1.110 PCMU/8000 20 ms 160 samples 2010-07-19 01:50:17.615937 [DEBUG] sofia_glue.c:3798 Set 2833 dtmf send/recv payload to 101 2010-07-19 01:50:17.615937 [DEBUG] sofia.c:4468 (sofia/internal/ 1000(a)192.168.1.110) State Change CS_NEW -> CS_INIT 2010-07-19 01:50:17.615937 [DEBUG] switch_core_session.c:1027 Send signal sofia/internal/1000(a)192.168.1.110 [BREAK] 2010-07-19 01:50:17.617033 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/1000(a)192.168.1.110) Running State Change CS_INIT 2010-07-19 01:50:17.617033 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/1000(a)192.168.1.110) State INIT 2010-07-19 01:50:17.617033 [DEBUG] mod_sofia.c:83 sofia/internal/ 1000(a)192.168.1.110 SOFIA INIT 2010-07-19 01:50:17.617033 [DEBUG] mod_sofia.c:119 (sofia/internal/ 1000(a)192.168.1.110) State Change CS_INIT -> CS_ROUTING 2010-07-19 01:50:17.617033 [DEBUG] switch_core_session.c:1027 Send signal sofia/internal/1000(a)192.168.1.110 [BREAK] 2010-07-19 01:50:17.617033 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/1000(a)192.168.1.110) State INIT going to sleep 2010-07-19 01:50:17.617033 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/1000(a)192.168.1.110) Running State Change CS_ROUTING 2010-07-19 01:50:17.617033 [DEBUG] switch_channel.c:1471 (sofia/internal/ 1000(a)192.168.1.110) Callstate Change DOWN -> RINGING 2010-07-19 01:50:17.617033 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/1000(a)192.168.1.110) State ROUTING 2010-07-19 01:50:17.617033 [DEBUG] mod_sofia.c:142 sofia/internal/ 1000(a)192.168.1.110 SOFIA ROUTING 2010-07-19 01:50:17.617033 [DEBUG] switch_core_state_machine.c:77 sofia/internal/1000(a)192.168.1.110 Standard ROUTING 2010-07-19 01:50:17.617033 [INFO] mod_dialplan_xml.c:331 Processing 1000->12345 in context default Dialplan: sofia/internal/1000(a)192.168.1.110 parsing [default->unloop] continue=false Dialplan: sofia/internal/1000(a)192.168.1.110 Regex (PASS) [unloop] ${unroll_loops}(true) =~ /^true$/ break=on-false Dialplan: sofia/internal/1000(a)192.168.1.110 Regex (FAIL) [unloop] ${sip_looped_call}() =~ /^true$/ break=on-false Dialplan: sofia/internal/1000(a)192.168.1.110 parsing [default->outgoing-pri] continue=false Dialplan: sofia/internal/1000(a)192.168.1.110 Regex (PASS) [outgoing-pri] destination_number(12345) =~ /12345/ break=on-false Dialplan: sofia/internal/1000(a)192.168.1.110 Action bridge(OpenZAP/smg_prid/a/09677012480@g1) 2010-07-19 01:50:17.618002 [DEBUG] switch_core_state_machine.c:119 (sofia/internal/1000(a)192.168.1.110) State Change CS_ROUTING -> CS_EXECUTE 2010-07-19 01:50:17.618002 [DEBUG] switch_core_session.c:1027 Send signal sofia/internal/1000(a)192.168.1.110 [BREAK] 2010-07-19 01:50:17.618002 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/1000(a)192.168.1.110) State ROUTING going to sleep 2010-07-19 01:50:17.618002 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/1000(a)192.168.1.110) Running State Change CS_EXECUTE 2010-07-19 01:50:17.618002 [DEBUG] switch_core_state_machine.c:348 (sofia/internal/1000(a)192.168.1.110) State EXECUTE 2010-07-19 01:50:17.618002 [DEBUG] mod_sofia.c:235 sofia/internal/ 1000(a)192.168.1.110 SOFIA EXECUTE 2010-07-19 01:50:17.618002 [DEBUG] switch_core_state_machine.c:157 sofia/internal/1000(a)192.168.1.110 Standard EXECUTE EXECUTE sofia/internal/1000@192.168.1.110bridge(OpenZAP/smg_prid/a/09677012480@g1 ) 2010-07-19 01:50:17.619035 [DEBUG] mod_openzap.c:403 Set codec PCMA 20ms 2010-07-19 01:50:17.619035 [DEBUG] mod_openzap.c:1317 Connect outbound channel OpenZAP/1:1/09677012480@g1 2010-07-19 01:50:17.619035 [NOTICE] switch_channel.c:776 New Channel OpenZAP/1:1/09677012480@g1 [36c14872-c8e1-4fa4-94ea-8c075d5133d2] 2010-07-19 01:50:17.619035 [DEBUG] mod_openzap.c:1331 (OpenZAP/1:1/09677012480@g1) State Change CS_NEW -> CS_INIT 2010-07-19 01:50:17.619035 [DEBUG] switch_core_session.c:1027 Send signal OpenZAP/1:1/09677012480@g1 [BREAK] 2010-07-19 01:50:17.619035 [DEBUG] ozmod_analog.c:59 Changing state on 1:1 from DOWN to DIALING 2010-07-19 01:50:17.620937 [DEBUG] ozmod_analog.c:293 ANALOG CHANNEL thread starting. 2010-07-19 01:50:17.620937 [DEBUG] ozmod_analog.c:464 Executing state handler on 1:1 for DIALING 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:314 (OpenZAP/1:1/09677012480@g1) Running State Change CS_INIT 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:338 (OpenZAP/1:1/09677012480@g1) State INIT 2010-07-19 01:50:17.633931 [DEBUG] mod_openzap.c:431 (OpenZAP/1:1/09677012480@g1) State Change CS_INIT -> CS_ROUTING 2010-07-19 01:50:17.633931 [DEBUG] switch_core_session.c:1027 Send signal OpenZAP/1:1/09677012480@g1 [BREAK] 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:338 (OpenZAP/1:1/09677012480@g1) State INIT going to sleep 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:314 (OpenZAP/1:1/09677012480@g1) Running State Change CS_ROUTING 2010-07-19 01:50:17.633931 [DEBUG] switch_channel.c:1471 (OpenZAP/1:1/09677012480@g1) Callstate Change DOWN -> RINGING 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:341 (OpenZAP/1:1/09677012480@g1) State ROUTING 2010-07-19 01:50:17.633931 [DEBUG] mod_openzap.c:454 OpenZAP/1:1/09677012480@g1 CHANNEL ROUTING 2010-07-19 01:50:17.633931 [DEBUG] switch_ivr_originate.c:64 (OpenZAP/1:1/09677012480@g1) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2010-07-19 01:50:17.633931 [DEBUG] switch_core_session.c:1027 Send signal OpenZAP/1:1/09677012480@g1 [BREAK] 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:341 (OpenZAP/1:1/09677012480@g1) State ROUTING going to sleep 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:314 (OpenZAP/1:1/09677012480@g1) Running State Change CS_CONSUME_MEDIA 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:360 (OpenZAP/1:1/09677012480@g1) State CONSUME_MEDIA 2010-07-19 01:50:17.633931 [DEBUG] switch_core_state_machine.c:360 (OpenZAP/1:1/09677012480@g1) State CONSUME_MEDIA going to sleep 2010-07-19 01:50:47.638427 [DEBUG] ozmod_analog.c:354 Changing state on 1:1 from DIALING to BUSY 2010-07-19 01:50:47.658427 [DEBUG] ozmod_analog.c:464 Executing state handler on 1:1 for BUSY 2010-07-19 01:50:47.658427 [DEBUG] ozmod_analog.c:593 Changing state on 1:1 from BUSY to DOWN 2010-07-19 01:50:47.678427 [DEBUG] ozmod_analog.c:464 Executing state handler on 1:1 for DOWN 2010-07-19 01:50:47.678427 [WARNING] mod_openzap.c:2038 Unhandled analog channel type 0 for channel 1:1 2010-07-19 01:50:47.678427 [DEBUG] zap_io.c:1388 channel done 1:1 2010-07-19 01:50:47.678427 [DEBUG] ozmod_analog.c:778 ANALOG CHANNEL 1:1 thread ended. 2010-07-19 01:51:16.667683 [DEBUG] sofia.c:4310 Channel sofia/internal/ 1000(a)192.168.1.110 entering state [terminated][487] 2010-07-19 01:51:16.667683 [DEBUG] switch_channel.c:2261 (sofia/internal/ 1000(a)192.168.1.110) Callstate Change RINGING -> HANGUP 2010-07-19 01:51:16.667683 [NOTICE] sofia.c:4924 Hangup sofia/internal/ 1000(a)192.168.1.110 [CS_EXECUTE] [ORIGINATOR_CANCEL] 2010-07-19 01:51:16.667683 [DEBUG] switch_channel.c:2277 Send signal sofia/internal/1000(a)192.168.1.110 [KILL] 2010-07-19 01:51:16.667683 [DEBUG] switch_core_session.c:1027 Send signal sofia/internal/1000(a)192.168.1.110 [BREAK] 2010-07-19 01:51:16.667683 [DEBUG] switch_channel.c:2261 (OpenZAP/1:1/09677012480@g1) Callstate Change RINGING -> HANGUP 2010-07-19 01:51:16.667683 [NOTICE] switch_ivr_originate.c:3220 Hangup OpenZAP/1:1/09677012480@g1 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2010-07-19 01:51:16.667683 [DEBUG] switch_channel.c:2277 Send signal OpenZAP/1:1/09677012480@g1 [KILL] 2010-07-19 01:51:16.667683 [DEBUG] switch_core_session.c:1027 Send signal OpenZAP/1:1/09677012480@g1 [BREAK] 2010-07-19 01:51:16.667683 [DEBUG] switch_ivr_originate.c:3363 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-07-19 01:51:16.667683 [INFO] mod_dptools.c:2382 Originate Failed. Cause: ORIGINATOR_CANCEL 2010-07-19 01:51:16.667683 [DEBUG] switch_core_state_machine.c:314 (OpenZAP/1:1/09677012480@g1) Running State Change CS_HANGUP 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:348 (sofia/internal/1000(a)192.168.1.110) State EXECUTE going to sleep 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/1000(a)192.168.1.110) Running State Change CS_HANGUP 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:500 (OpenZAP/1:1/09677012480@g1) State HANGUP 2010-07-19 01:51:16.669919 [DEBUG] mod_openzap.c:556 OpenZAP/1:1/09677012480@g1 CHANNEL HANGUP 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:46 OpenZAP/1:1/09677012480@g1 Standard HANGUP, cause: ORIGINATOR_CANCEL 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:500 (OpenZAP/1:1/09677012480@g1) State HANGUP going to sleep 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:333 (OpenZAP/1:1/09677012480@g1) State Change CS_HANGUP -> CS_REPORTING 2010-07-19 01:51:16.669919 [DEBUG] switch_core_session.c:1027 Send signal OpenZAP/1:1/09677012480@g1 [BREAK] 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:314 (OpenZAP/1:1/09677012480@g1) Running State Change CS_REPORTING 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:591 (OpenZAP/1:1/09677012480@g1) State REPORTING 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:53 OpenZAP/1:1/09677012480@g1 Standard REPORTING, cause: ORIGINATOR_CANCEL 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:591 (OpenZAP/1:1/09677012480@g1) State REPORTING going to sleep 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:327 (OpenZAP/1:1/09677012480@g1) State Change CS_REPORTING -> CS_DESTROY 2010-07-19 01:51:16.669919 [DEBUG] switch_core_session.c:1027 Send signal OpenZAP/1:1/09677012480@g1 [BREAK] 2010-07-19 01:51:16.669919 [DEBUG] switch_core_session.c:1175 Session 33 (OpenZAP/1:1/09677012480@g1) Locked, Waiting on external entities 2010-07-19 01:51:16.669919 [NOTICE] switch_core_session.c:1193 Session 33 (OpenZAP/1:1/09677012480@g1) Ended 2010-07-19 01:51:16.669919 [NOTICE] switch_core_session.c:1195 Close Channel OpenZAP/1:1/09677012480@g1 [CS_DESTROY] 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:500 (sofia/internal/1000(a)192.168.1.110) State HANGUP 2010-07-19 01:51:16.669919 [DEBUG] mod_sofia.c:449 sofia/internal/ 1000(a)192.168.1.110 Overriding SIP cause 487 with 487 from the other leg 2010-07-19 01:51:16.669919 [DEBUG] mod_sofia.c:455 Channel sofia/internal/ 1000(a)192.168.1.110 hanging up, cause: ORIGINATOR_CANCEL 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:427 (OpenZAP/1:1/09677012480@g1) Callstate Change HANGUP -> DOWN 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:430 (OpenZAP/1:1/09677012480@g1) Running State Change CS_DESTROY 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:440 (OpenZAP/1:1/09677012480@g1) State DESTROY 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:60 OpenZAP/1:1/09677012480@g1 Standard DESTROY 2010-07-19 01:51:16.669919 [DEBUG] switch_core_state_machine.c:440 (OpenZAP/1:1/09677012480@g1) State DESTROY going to sleep 2010-07-19 01:51:16.699683 [DEBUG] switch_core_state_machine.c:46 sofia/internal/1000(a)192.168.1.110 Standard HANGUP, cause: ORIGINATOR_CANCEL 2010-07-19 01:51:16.699683 [DEBUG] switch_core_state_machine.c:500 (sofia/internal/1000(a)192.168.1.110) State HANGUP going to sleep 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:333 (sofia/internal/1000(a)192.168.1.110) State Change CS_HANGUP -> CS_REPORTING 2010-07-19 01:51:16.701682 [DEBUG] switch_core_session.c:1027 Send signal sofia/internal/1000(a)192.168.1.110 [BREAK] 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/1000(a)192.168.1.110) Running State Change CS_REPORTING 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:591 (sofia/internal/1000(a)192.168.1.110) State REPORTING 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1000(a)192.168.1.110 Standard REPORTING, cause: ORIGINATOR_CANCEL 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:591 (sofia/internal/1000(a)192.168.1.110) State REPORTING going to sleep 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:327 (sofia/internal/1000(a)192.168.1.110) State Change CS_REPORTING -> CS_DESTROY 2010-07-19 01:51:16.701682 [DEBUG] switch_core_session.c:1027 Send signal sofia/internal/1000(a)192.168.1.110 [BREAK] 2010-07-19 01:51:16.701682 [DEBUG] switch_core_session.c:1175 Session 32 (sofia/internal/1000(a)192.168.1.110) Locked, Waiting on external entities 2010-07-19 01:51:16.701682 [NOTICE] switch_core_session.c:1193 Session 32 (sofia/internal/1000(a)192.168.1.110) Ended 2010-07-19 01:51:16.701682 [NOTICE] switch_core_session.c:1195 Close Channel sofia/internal/1000(a)192.168.1.110 [CS_DESTROY] 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:427 (sofia/internal/1000(a)192.168.1.110) Callstate Change HANGUP -> DOWN 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:430 (sofia/internal/1000(a)192.168.1.110) Running State Change CS_DESTROY 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:440 (sofia/internal/1000(a)192.168.1.110) State DESTROY 2010-07-19 01:51:16.701682 [DEBUG] mod_sofia.c:360 sofia/internal/ 1000(a)192.168.1.110 SOFIA DESTROY 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:60 sofia/internal/1000(a)192.168.1.110 Standard DESTROY 2010-07-19 01:51:16.701682 [DEBUG] switch_core_state_machine.c:440 (sofia/internal/1000(a)192.168.1.110) State DESTROY going to sleep Thanks in advance, Regards, Venkat.

4 7

voice mail to email silently failing
by Alan Dawson 21 Jul '10

21 Jul '10

Hi, I'm running FreeSWITCH Version 1.0.head (git-1cbf30a 2010-07-02 20-19-03 -0300) I've configured a mailbox like <params> <param name="password" value="$${default_password}"/> <param name="vm-password" value="1000"/> <param name="vm-email-all-messages" value="true"/> <param name="vm-attach-file" value="true"/> <param name="vm-mailto" value="aland(a)burngreave.net"/> </params> and tried several variations on <param name="mailer-app" value="/usr/local/bin/eximcompat.sh"/>  or using the perl script http://svn.freeswitch.org/svn/freeswitch/trunk/scripts/perl/sendmail in switch.conf.xml In my freeswitch.log I see 2010-07-14 02:37:49.664750 [DEBUG] switch_utils.c:631 Emailed file [/tmp/mail.12790714694210] to [aland(a)burngreave.net] 2010-07-14 02:37:49.668750 [DEBUG] mod_voicemail.c:2571 Sending message to aland(a)burngreave.net 2010-07-14 02:41:57.277097 [DEBUG] switch_utils.c:631 Emailed file [/tmp/mail.12790717177ad8] to [aland(a)burngreave.net] 2010-07-14 02:41:57.277097 [DEBUG] mod_voicemail.c:2571 Sending message to aland(a)burngreave.net but no email is delivered, nor any entries appear in my MTA logs I _do_ have a working MTA on this machine, and if I ( as user freeswitch or root ) do cat /tmp/msg.txt | /usr/local/bin/eximcompat.sh mail is successfully sent and delivered. Thanks in advance, -- Alan Dawson

1 1

TLS error?
by Federico Beffa 21 Jul '10

21 Jul '10

Hi All, I've found the problem: for some reason, during installation (make install) mod_dingaling is not linked against libgnutls.so. As a test I have added the "-lgnutls" switch in src/mod/endpoints/mod_dingaling/mod_dingaling.la to gcc in the relink_command. After re-issuing "make install" everything works fine and I can connect to gtalk. I guess this can be classified as a "configure" error. Regards, Fede

1 0

Slightly OT: Pulling specific git "revisions"
by Kristian Kielhofner 21 Jul '10

21 Jul '10

Hello everyone, I've got scripts for building specific SVN revisions of FreeSWITCH (for AstLinux, etc). How do I best accomplish this with git? I'm looking for something like this: svn co -r 17856 ...but for git. Any ideas? I've looked at various git docs, sites, etc and I can't seem to come up with something equivalent. -- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com

3 2

RTP Timing
by Neil Burgess 21 Jul '10

21 Jul '10

Hi, We are capturing packets for call quality monitoring purposes, and as part of the capture, we are grabbing the outbound packets from FreeSwitch. We are noticing what appears to be an odd behaviour in the RTP sequence timing where suddenly the timing will jump from the regular 160 increments to a number in the 10's of millions! See packet 38 below. Now I have no idea as to whether such a timing change is OK in RTP, and although the actual RTP stream does not appear to be affected, I do see that Wireshark believes there is a massive amount of jitter on the line when it analyses the packets, and any RTCP Sender Reports from the target device (and indeed several different target types have been tried) also report very large inter arrival jitter numbers at this point! It's the RTCP side of things that are more of interest here, as trying to get accurate results of our downstream jitter by capturing the returned RTCP packets. I believe that all the times we see this, there is however a Marker bit present! So I guess the question is whether this is expected behaviour, and if not any ideas? No. Time Source Destination Protocol Info 1 0.000000 gmtpbx02.redmatter.com sil1.magrathea.net SIP/SDP Request: INVITE sip:441277849884@sipipgw.magrathea.net, with session description 2 0.001595 sil1.magrathea.net gmtpbx02.redmatter.com SIP Status: 100 Giving a try 3 1.103160 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=0, Time=0 4 1.124816 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=1, Time=160 5 1.142758 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=2, Time=320 6 1.163702 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=3, Time=480 7 1.184239 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=4, Time=640 8 1.203259 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=5, Time=800 9 1.223456 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=6, Time=960 10 1.243953 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=7, Time=1120 11 1.264504 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=8, Time=1280 12 1.284839 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=9, Time=1440 13 1.304590 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=10, Time=1600 14 1.323589 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=11, Time=1760 15 1.344672 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=12, Time=1920 16 1.359227 sil1.magrathea.net gmtpbx02.redmatter.com SIP/SDP Status: 183 Session Progress, with session description 17 1.364522 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=13, Time=2080 18 1.377484 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53974, Time=160, Mark 19 1.383466 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=14, Time=2240 20 1.397476 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53975, Time=320 21 1.403953 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=15, Time=2400 22 1.417484 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53976, Time=480 23 1.423616 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=16, Time=2560 24 1.437474 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53977, Time=640 25 1.444930 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=17, Time=2720 26 1.457475 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53978, Time=800 27 1.463341 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=18, Time=2880 28 1.477473 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53979, Time=960 29 1.484235 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=19, Time=3040 30 1.497483 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53980, Time=1120 31 1.503415 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=20, Time=3200 32 1.517474 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53981, Time=1280 33 1.523541 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=21, Time=3360 34 1.537472 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53982, Time=1440 35 1.543428 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=22, Time=3520 36 1.557567 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53983, Time=1600 37 1.563656 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=23, Time=3680 38 1.577496 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53984, Time=130238272, Mark 39 1.584747 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=24, Time=3840 40 1.597474 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53985, Time=130238432 41 1.603871 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=25, Time=4000 42 1.617465 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53986, Time=130238432 43 1.624224 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=26, Time=4160 44 1.637466 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53987, Time=130238592 Many thanks, Neil

5 6

Conf Call Just Started!
by Michael Collins 21 Jul '10

21 Jul '10

Here's today's agenda page: http://wiki.freeswitch.org/wiki/FS_weekly_2010_07_21 -MC

1 0

Re: [Freeswitch-users] calls ending with MEDIA_TIMEOUT
by Dan 21 Jul '10

21 Jul '10

Gotcha, if I sort wireshark by source freeswitch sends 2 RTP packets and then a handful if ICMP errors, this pattern repeats for the entire call (2 voice packets and 5+ icmp errors). 192.168.24.22 = freeswitch 192.168.21.4 = endpoint ID Time Source Src Port Destination Dest Port 12 0.186121 192.168.24.22 27176 192.168.21.4 16752 RTP PT=ITU-T G.711 PCMU, SSRC=0x33CF6C8, Seq=5202, Time=240, Mark 13 0.186126 192.168.24.22 27176 192.168.21.4 16752 RTP PT=ITU-T G.711 PCMU, SSRC=0x33CF6C8, Seq=5202, Time=240, Mark 57 1.477101 192.168.24.22 16752 192.168.21.4 27176 ICMP Destination unreachable (Port unreachable) 92 2.467948 192.168.24.22 16752 192.168.21.4 27176 ICMP Destination unreachable (Port unreachable) 93 2.467949 192.168.24.22 16752 192.168.21.4 27176 ICMP Destination unreachable (Port unreachable) 194 5.465388 192.168.24.22 16752 192.168.21.4 27176 ICMP Destination unreachable (Port unreachable) The ICMP erros have the ports reversed, is this normal ? Thanks, Dan- From: "Brian West" <brian(a)freeswitch.org> To: "FreeSWITCH Users Help" <freeswitch-users(a)lists.freeswitch.org> Sent: Wednesday, July 21, 2010 8:30:40 AM Subject: Re: [Freeswitch-users] calls ending with MEDIA_TIMEOUT NO that would mean that it was sending RTP to that IP and the firewall returned and ICMP port unreachable. /b On Jul 21, 2010, at 8:43 AM, Dan wrote: > I was able to pull the box out yesterday and try some load testing under tcpdump. It looks like under load freeswitch was trying to ping the far end RTP port which was failing: > > 57 1.477101 192.168.24.22 192.168.21.4 ICMP Destination unreachable (Port unreachable) > > I'm guessing this is part of auto nat detection? Is this a tunable option? I don't need stun/nat functionality at this point so I'm running freeswitch with the -nonat flag right now to see if its playing a part here. > > I have the tcpdump of a call if anyone is interested. > > Thanks > Dan- _______________________________________________ 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

1 0

calls ending with MEDIA_TIMEOUT
by Dan 21 Jul '10

21 Jul '10

Hi guys, I have been running two freeswitch boxes (13754M) that answer calls from a cisco 5300 (both on the same network) and records them to disk with a small lua application. This has been working well for the past few months. I decided to upgrade one of them to trunk ( git-3fbd9e2 2010-06-11 11-08-51 -0500 ) and have run into a problem. Some calls will fail with a MEDIA_TIMEOUT after a few minutes, the time it takes to fail ranges from 4 minutes to 10 minutes, I don't have a full sip trace or pcap dump yet, I reverted back to the old freeswitch version (on the same hardware) and have not been able to reproduce it in a test environment yet ( I continue to try). Below are the relevant lines from the log files for one of the calls: 2010-06-23 07:42:19.033466 [DEBUG] switch_channel.c:2257 (sofia/external/nobody(a)192.168.21.4) Callstate Change ACTIVE -> HANGUP 2010-06-23 07:42:19.033466 [NOTICE] mod_sofia.c:884 Hangup sofia/external/nobody(a)192.168.21.4 [CS_EXECUTE] [MEDIA_TIMEOUT] 2010-06-23 07:42:19.033466 [DEBUG] switch_channel.c:2273 Send signal sofia/external/nobody(a)192.168.21.4 [KILL] 2010-06-23 07:42:19.033466 [DEBUG] switch_core_session.c:1023 Send signal sofia/external/nobody(a)192.168.21.4 [BREAK] 2010-06-23 07:42:19.033466 [DEBUG] switch_core_codec.c:146 sofia/external/nobody(a)192.168.21.4 Restore previous codec PCMU:0. My configuration is bone stock, so the rtp timeout value is at 300, but I have some calls that have lasted only 4 minutes. One other piece of information is that on one of the recordings that was hung up after 4 minutes and 17 seconds the recorded file was only 24 seconds long (it stopped recording after the first 24 seconds) , so I'm assuming freeswitch did not think there were any rtp packets to record. Any ideas on where to start debugging this? I have setup a new freeswitch box connected to the same 5300 to reproduce, but have not been able to generate the call volume ( there where around 30 calls being recorded) yet, but I'm working on it. Thanks!

4 6

Re: [Freeswitch-users] Howler - Gone?
by Kristian Kielhofner 21 Jul '10

21 Jul '10

I was working on a project with IBM, speex, and the University of Sao Paulo to do this a few years ago. Very interesting. Either way Sony disabled the "install other OS" feature so no more Linux on the PS3. -- Kristian Kielhofner http://blog.krisk.org ----- Original Message ----- From: freeswitch-users-bounces(a)lists.freeswitch.org <freeswitch-users-bounces(a)lists.freeswitch.org> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Sent: Tue Jul 20 22:00:50 2010 Subject: Re: [Freeswitch-users] Howler - Gone? But finally howler show to us something good: With the Cell chips used in the Leadteck (are the same on a PS3), we can make a transcoding equipment with a PS3 for $299 USD... :) Using the Ethernet of the PS3 we can send the RTP to the transcoding software and the device has enough power to convert 400+ concurrent calls.... only think about it. Best Regards... Fernando Romo On Jul 20, 2010, at 7:50 PM, Steve Underwood wrote: > On 07/21/2010 08:42 AM, Moises Silva wrote: >> On Tue, Jul 20, 2010 at 8:33 PM, Steve Underwood <steveu(a)coppice.org >> <mailto:steveu@coppice.org>> wrote: >> >> Someone may be able to give you a copy of the drivers, but won't you >> need access to Howler's licencing server to enable your licences? >> >> >> At least with Sangoma transcoding card you don't need any servers to >> enable licensing (and you have a bunch of codecs, not just G729). >> > You have a custom card at Sangoma, so I guess you have more fine grained > control with the card itself. Howler just used commercial Cell based > cards from Leadtek, and had to live with their strengths and weaknesses. > Since they sold the licences separate from the card, so you could buy a > card with just a few licences for a sensible price, I think they tied > down the licences in the same way they did for codecs running on the > server's CPU. Perhaps an actual Howler user could chime in here with > more info. > > Steve > > > > _______________________________________________ > 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 _______________________________________________ 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

1 0

ESL: api command
by Helmut Kuper 21 Jul '10

21 Jul '10

Hello, I have an inbound ESL script which has subscribed to several events. So there is more or less a continuing stream of events. When it sends a blocking api command to FS is it there a risk to get back an event first before FS sends the command reply or does FS guarantee that the command reply is always next after issuing a api command? regards helmut

3 3