February 2010 - freeswitch-dev@lists.freeswitch.org

[Freeswitch-dev] REMINDER: FreeSWITCH Conf Call Moved to Wednesday!
by Michael Collins 24 Feb '10

24 Feb '10

Hi all, Just a reminder that we are meeting up on Wednesay morning. Here's the agenda: http://wiki.freeswitch.org/wiki/FS_weekly_2010_02_24 It is light since we only had a few days since our meeting last Friday. Remember that I won't be in right at the start of the meeting because I will be taking my kids to school. Please feel free to use that time to mingle... Thanks, Michael

1 0

[Freeswitch-dev] Possible bug in mod_conference.c
by Peter Fowler 22 Feb '10

22 Feb '10

In revision 16249 I am seeing an intermittent problem as follows: 1) conference is setup to play an alone sound and moh 2) first person calls into the conference 3) very intermittently the "alone" sound if not heard. Instead moh is played immediately I have tracked this down to a race condition in mod_conference where the line 1011 within conference_thread_run() checks the value of conference->async_fnode at the same time, on a separate thread, conference_add_member() is updating that value via conference_play_file. As a result, intermittently, the alone sound is enqueued but then immediately "over written" by the moh found. A possible solution would be to surround the if statement at 1011 with switch_mutex_lock(conference->mutex) ... switch_mutex_unlock(conference->mutex) Let me know if I should go ahead and enter a Jira and post a patch. Peter

2 1

[Freeswitch-dev] unsetInputCallback removes setHangupHook also...
by rentmycoder rentmycoder 22 Feb '10

22 Feb '10

Hi guys, Freeswitch Rocks! I use latest trunk on Win7 and if I call in lua on A-leg in that order: session:setHangupHook() session:setInputCallback() session:streamFile() session:unsetInputCallback() than the HangupHook does not get called. If I reissue session:setHangupHook() again then HangupHook is called again. Should this work like this? Can happen the situation than tha hangup occures AFTER unsetInputCallback() is called and BEFORE setHangupHook() is called again so I'll miss the hanguphook in this case??? If yes, how to avoid this? Thanks a lot...

2 1

[Freeswitch-dev] limit call on trunks based on call count
by rentmycoder rentmycoder 22 Feb '10

22 Feb '10

Hi Guys, Freeswitch Rocks! I would need to limit calls on outgoing profiles, eg. use maximum 2 calls on profile#1, if call count reached then use profile#2. In Asterisk I used Group()=trunk#1 and GROUP_COUNT(trunk#1) to achive this but cannot find any usefull hint how to do this using Freeswitch... Please advise...

2 1

[Freeswitch-dev] Need some direction
by Mark Sobkow 21 Feb '10

21 Feb '10

I need to create a custom Freeswitch module that acts as a leg/endpoint of a call. Unlike a conference, it needs to maintain a UUID so that a parked call can be bridged to it. Once the call is bridged, the module will be in "connect" mode. After the bridged leg disconnects, the module goes into "data collection" mode and gets DTMF call results from the operator. It then goes into a "parked" mode, waiting for another call to be bridged to it or for the operator to hit a DTMF logout sequence. I just need to know what I should look at for a template/sample to start with. Conferences don't seem to be applicable because they don't have UUIDs for bridging (I'd tried doing this behaviour using them and failed miserably.) The code for audio_bridge_function is interesting, but I don't believe that's what I need to start with either, as it _bridges_ calls rather than providing a virtual endpoint. Just to make things real interesting, I'll have to have the custom module generating custom events so that the Erlang control code gets notified with the call results so it can update an RDBMS with the result code. If I decide to get fancy, I'd like to have a mini-IVR associated with it that can provide voice prompts about the result codes available to the operator. Last but not least, I'm uncertain as to whether such a custom module needs to be "released" to the Freeswitch team, or whether it would be an "internal only" module. Hopefully it _has_ to be released -- I'd like to contribute in some small way to the community. As a "for example", picture the tech support call center -- after each call the operator/tech has to enter a code indicating whether the call was 1) handled; 2) passed to level 2 tech support; 3) passed to level 3 tech support; or 4) scheduled for callback. -- Mark Sobkow Senior Developer MarkeTel Multi-Line Dialing Systems LTD. 428 Victoria Ave Regina, SK S4N-0P6 Toll-Free: 800-289-8616-X533 Local: 306-359-6893-X533 Fax: 306-359-6879 Email: m.sobkow(a)marketelsystems.com Web: http://www.marketelsystems.com

2 1

[Freeswitch-dev] FreeSWITCH Conference Call Starting Shortly!
by Michael Collins 19 Feb '10

19 Feb '10

Come on in! http://wiki.freeswitch.org/wiki/FS_weekly_2010_02_19 -Michael

1 0

[Freeswitch-dev] json cdr
by Tamas Cseke 18 Feb '10

18 Feb '10

Hello, We would like to develop a json cdr module. It would be very similar like the mod_xml_cdr module, we'd like to post the cdr to an url. The only difference would be the format. The reason is that cdrs would be smaller. Maybe the parsing would be faster too. I made the same format as xml has, but we are not satisfied with this solution yet. We can't decide wheater we should create a new module (in this case we need to copy bunch of code from mod_xml_cdr like.: config, curl posts, file handling so we don't like this idea) or add it to mod_xml_cdr For prototype I hacked this into mod_xml_cdr svn diff -r 16686:16687 http://svn.freeswitch.org:/svn/freeswitch/branches/cseket/src/mod/xml_int/m… I added the functions to generate the cdrs into the module instead of creating core functions like the xml functions, because I think linking json to the core is not a good idea (?) The disadvantage of this version is that xml_cdr module creating json cdrs would be ridiculous :) Maybe could we make a single module with optional formats like: <param name="format" value="xml|json"/> with xml default? So I would like to ask advices how to do it properly. we would be happy if it could get into the trunk, but for this we have to work more on this. Thanks in advance, Tamas

1 0

Re: [Freeswitch-dev] [Freeswitch-users] Sending message notifications with openzap
by François Legal 18 Feb '10

18 Feb '10

Thanks, yes I could see that this was handled with events. Could you please give more details (that does not seem obvious to me while looking at sofia_presence.c) When and why is the event triggered ? What information do I get with the event ? Then I have a design question, is it mandatory to (as this is done in mod_sofia but I guess for a lot of reasons) process the event in a separate thread ? Thanks for the information (and sorry if my questions are not relevant, I don't know the event system at all). François On Thu, 18 Feb 2010 00:13:08 -0500, Michael Jerris wrote: This all uses the event system. Take a look at how we handle the events in mod_sofia, it should be pretty easy to do the same in mod_openzap. Mike On Feb 16, 2010, at 4:33 AM, François Legal wrote: I was wondering whether or not a facility was available to send message waiting indicator (from mpd_voicemail) using openzap. I know this feature is not available in openzap (I'm in the process of coding it for analog channels) but as message indication can be sent via mod_sofia, I wonder if a frame is available in FS core.

1 0

[Freeswitch-dev] stop originate_retries after hangup
by andre phan 18 Feb '10

18 Feb '10

I am having a problem whenever I use originate_retries when using bridge. If the caller on leg A hangs up before anyone on the B leg picks up, the call will continue to attempt to originate until all retries are filled. I will need both channels to close and not attempt to keep attempting to originate when the caller hangs up. Below is the output log of the call: 2010-02-17 14:44:16.567487 [NOTICE] switch_ivr_originate.c:2026 Hangup sofia/external/5555551234 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [DEBUG] switch_channel.c:1715 Send signal sofia/external/5555551234 [KILL] 2010-02-17 14:44:16.567487 [DEBUG] switch_core_session.c:932 Send signal sofia/external/5555551234 [BREAK] 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:398 (sofia/external/5555551234) Running State Change CS_HANGUP 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:533 thread mismatch skipping state handler. 2010-02-17 14:44:16.567487 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:16.567487 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 2/3 in 1000 ms 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:560 (sofia/external/5555551234) State HANGUP 2010-02-17 14:44:16.567487 [DEBUG] mod_sofia.c:338 Channel sofia/external/5555551234 hanging up, cause: ORIGINATOR_CANCEL 2010-02-17 14:44:16.567487 [DEBUG] mod_sofia.c:386 Sending CANCEL to sofia/external/5555551234 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:46 sofia/external/5555551234 Standard HANGUP, cause: ORIGINATOR_CANCEL 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:560 (sofia/external/5555551234) State HANGUP going to sleep 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:417 (sofia/external/5555551234) State Change CS_HANGUP -> CS_REPORTING 2010-02-17 14:44:16.567487 [DEBUG] switch_core_session.c:932 Send signal sofia/external/5555551234 [BREAK] 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:398 (sofia/external/5555551234) Running State Change CS_REPORTING 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:651 (sofia/external/5555551234) State REPORTING 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:53 sofia/external/5555551234 Standard REPORTING, cause: ORIGINATOR_CANCEL 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:651 (sofia/external/5555551234) State REPORTING going to sleep 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:411 (sofia/external/5555551234) State Change CS_REPORTING -> CS_DESTROY 2010-02-17 14:44:16.567487 [DEBUG] switch_core_session.c:932 Send signal sofia/external/5555551234 [BREAK] 2010-02-17 14:44:16.567487 [DEBUG] switch_core_session.c:1069 Session 2 (sofia/external/5555551234) Locked, Waiting on external entities 2010-02-17 14:44:16.567487 [NOTICE] switch_core_session.c:1087 Session 2 (sofia/external/5555551234) Ended 2010-02-17 14:44:16.567487 [NOTICE] switch_core_session.c:1089 Close Channel sofia/external/5555551234 [CS_DESTROY] 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:497 (sofia/external/5555551234) Running State Change CS_DESTROY 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:508 (sofia/external/5555551234) State DESTROY 2010-02-17 14:44:16.567487 [DEBUG] mod_sofia.c:255 sofia/external/5555551234 SOFIA DESTROY 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:60 sofia/external/5555551234 Standard DESTROY 2010-02-17 14:44:16.567487 [DEBUG] switch_core_state_machine.c:508 (sofia/external/5555551234) State DESTROY going to sleep 2010-02-17 14:44:17.567493 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:17.567493 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 2/3 in 1000 ms 2010-02-17 14:44:18.567500 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:18.567500 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 2/3 in 1000 ms 2010-02-17 14:44:19.567506 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:19.567506 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 2/3 in 1000 ms 2010-02-17 14:44:19.770633 [ALERT] switch_cpp.cpp:1130 CT - Update Balance 0cbcac65-003f-4053-a041-1795748a1941 -0.018 2010-02-17 14:44:20.067509 [DEBUG] switch_core_session.c:932 Send signal sofia/external/5555559876(a)10.10.10.15 [BREAK] 2010-02-17 14:44:20.067509 [DEBUG] switch_core_state_machine.c:533 thread mismatch skipping state handler. 2010-02-17 14:44:20.567513 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:20.567513 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 2/3 in 1000 ms 2010-02-17 14:44:21.567519 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:21.567519 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 2/3 in 1000 ms 2010-02-17 14:44:22.567525 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:22.567525 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 2/3 in 1000 ms 2010-02-17 14:44:23.567532 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:23.567532 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 2/3 in 1000 ms 2010-02-17 14:44:24.567538 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:24.567538 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 3/3 in 1000 ms 2010-02-17 14:44:25.567545 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:25.567545 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 3/3 in 1000 ms 2010-02-17 14:44:26.567551 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:26.567551 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 3/3 in 1000 ms 2010-02-17 14:44:27.567557 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:27.567557 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 3/3 in 1000 ms 2010-02-17 14:44:28.567564 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:28.567564 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 3/3 in 1000 ms 2010-02-17 14:44:29.567570 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:29.567570 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 3/3 in 1000 ms 2010-02-17 14:44:30.567577 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:30.567577 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 3/3 in 1000 ms 2010-02-17 14:44:31.567583 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:31.567583 [NOTICE] switch_ivr_originate.c:1317 Originate attempt 3/3 in 1000 ms 2010-02-17 14:44:32.567589 [DEBUG] switch_ivr_originate.c:2166 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL] 2010-02-17 14:44:32.567589 [INFO] mod_dptools.c:2114 Originate Failed. Cause: ORIGINATOR_CANCEL 2010-02-17 14:44:32.567589 [DEBUG] switch_cpp.cpp:571 CoreSession::hangup 2010-02-17 14:44:32.567589 [DEBUG] switch_cpp.cpp:571 CoreSession::hangup 2010-02-17 14:44:32.567589 [DEBUG] switch_cpp.cpp:921 destroy/unlink session from object 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:432 (sofia/external/5555559876(a)10.10.10.15) State EXECUTE going to sleep 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:398 (sofia/external/5555559876(a)10.10.10.15) Running State Change CS_HANGUP 2010-02-17 14:44:32.567589 [DEBUG] switch_core_media_bug.c:364 Removing BUG from sofia/external/5555559876(a)10.10.10.15 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:560 (sofia/external/5555559876(a)10.10.10.15) State HANGUP 2010-02-17 14:44:32.567589 [DEBUG] mod_sofia.c:338 Channel sofia/external/5555559876(a)10.10.10.15 hanging up, cause: NORMAL_CLEARING 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:46 sofia/external/5555559876(a)10.10.10.15 Standard HANGUP, cause: NORMAL_CLEARING 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:560 (sofia/external/5555559876(a)10.10.10.15) State HANGUP going to sleep 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:417 (sofia/external/5555559876(a)10.10.10.15) State Change CS_HANGUP -> CS_REPORTING 2010-02-17 14:44:32.567589 [DEBUG] switch_core_session.c:932 Send signal sofia/external/5555559876(a)10.10.10.15 [BREAK] 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:398 (sofia/external/5555559876(a)10.10.10.15) Running State Change CS_REPORTING 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:651 (sofia/external/5555559876(a)10.10.10.15) State REPORTING 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:53 sofia/external/5555559876(a)10.10.10.15 Standard REPORTING, cause: NORMAL_CLEARING 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:651 (sofia/external/5555559876(a)10.10.10.15) State REPORTING going to sleep 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:411 (sofia/external/5555559876(a)10.10.10.15) State Change CS_REPORTING -> CS_DESTROY 2010-02-17 14:44:32.567589 [DEBUG] switch_core_session.c:932 Send signal sofia/external/5555559876(a)10.10.10.15 [BREAK] 2010-02-17 14:44:32.567589 [DEBUG] switch_core_session.c:1069 Session 1 (sofia/external/5555559876(a)10.10.10.15) Locked, Waiting on external entities 2010-02-17 14:44:32.567589 [NOTICE] switch_core_session.c:1087 Session 1 (sofia/external/5555559876(a)10.10.10.15) Ended 2010-02-17 14:44:32.567589 [NOTICE] switch_core_session.c:1089 Close Channel sofia/external/5555559876(a)10.10.10.15 [CS_DESTROY] 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:497 (sofia/external/5555559876(a)10.10.10.15) Running State Change CS_DESTROY 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:508 (sofia/external/5555559876(a)10.10.10.15) State DESTROY 2010-02-17 14:44:32.567589 [DEBUG] mod_sofia.c:255 sofia/external/5555559876(a)10.10.10.15 SOFIA DESTROY 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:60 sofia/external/5555559876(a)10.10.10.15 Standard DESTROY 2010-02-17 14:44:32.567589 [DEBUG] switch_core_state_machine.c:508 (sofia/external/5555559876(a)10.10.10.15) State DESTROY going to sleep Thanks, Andre

3 3

[Freeswitch-dev] how to use mod_erlang ?
by daqiang wang 18 Feb '10

18 Feb '10

hi: I am testing mod_erlang, using the wiki: http://wiki.freeswitch.org/wiki/Mod_erlang_event I run : >{foo, freeswitch@localhost} ! {api, status, ""}. but returned: =ERROR REPORT==== 18-Feb-2010::10:17:44 === Error in process <0.47.0> on node 'test@wangdq-laptop' with exit value: {badarg,[{erlang,list_to_existing_atom,["freeswitch@wangdq-laptop "]},{dist_util,recv_challenge,1},{dist_util,handshake_we_started,1}]} {api,status,[]} and in the freeswitch console : 2010-02-18 10:17:44.470405 [NOTICE] mod_erlang_event.c:1720 Ignorable error in ei_accept - probable bad client version, bad cookie or bad nodename but , I checked the config file : it seems no problem : <configuration name="erlang_event.conf" description="Erlang Socket Client"> <settings> <param name="listen-ip" value="0.0.0.0"/> <param name="listen-port" value="8031"/> <param name="cookie" value="ClueCon"/> <param name="nodename" value="freeswitch"/> <param name="shortname" value="true"/>  <param name="apply-inbound-acl" value="lan"/>  <param name="encoding" value="string"/>   </settings> </configuration> ~ why ? can you help me ? thanks!

1 0