January 2011 - FreeSWITCH-users - FreeSWITCH Mailing Lists

How to filter Skypopen chat message in ESL mode?
by xuyan yang 27 Apr '11

27 Apr '11

hi, I am writing ESL program on FreeSWITCH Version 1.0.head (git-8825b6e 2010-11-28 17-15-39 -0500) I need to handle skype chat message with a inbound ESL connection. But there are 1 or 2 esl events received randomly for each message. the first short one is alway generated, but the second one is random. So when trying to filter according to UUID, nothing is caught in many cases. If I make filter based on skype ID, duplicated messages are often heard. I do not why the behavior of the second event is random. How should I setup the filter to get 1 and only 1 event for each chat message? Thanks. the first is a short one with the following header: [Event-Name] = [MESSAGE] [Event-Calling-Function] = [incoming_chatmessage] [Event-Date-GMT] = [Wed, 01 Dec 2010 21:02:37 GMT] [Core-UUID] = [7d858a18-fcb8-11df-8f82-835ae03a7500] [Content-Length] = [1] [subject] = [SIMPLE MESSAGE] [FreeSWITCH-IPv4] = [192.168.0.3] [hint] = [niqizhi] [from] = [niqizhi] [Event-Date-Local] = [2010-12-01 21:02:37] [proto] = [skype] [FreeSWITCH-IPv6] = [::1] [id] = [5334] [Event-Calling-File] = [mod_skypopen.c] [Event-Date-Timestamp] = [1291237357051788] [FreeSWITCH-Hostname] = [EYSRV] [login] = [interface1] [during-call] = [true] [Event-Calling-Line-Number] = [2915] [chatname] = [#niqizhi/$abcdericunion;631dd843d9b3eb1a] the second is much longer: [Caller-Source] = [mod_skypopen] [Event-Calling-Function] = [incoming_chatmessage] [Event-Date-GMT] = [Wed, 01 Dec 2010 21:02:37 GMT] [Answer-State] = [answered] [FreeSWITCH-IPv4] = [192.168.0.3] [Channel-State] = [CS_EXECUTE] [Channel-Read-Codec-Bit-Rate] = [256000] [FreeSWITCH-IPv6] = [::1] [Unique-ID] = [412764c0-fd8e-11df-9019-835ae03a7500] [Channel-Read-Codec-Rate] = [16000] [Caller-Destination-Number] = [5655] [Caller-Channel-Transfer-Time] = [0] [Channel-Call-State] = [ACTIVE] [Caller-Channel-Progress-Media-Time] = [0] [FreeSWITCH-Hostname] = [EYSRV] [Caller-Channel-Answered-Time] = [1291237326697085] [login] = [interface1] [during-call] = [true] [Channel-Name] = [skypopen/interface1] [Caller-Unique-ID] = [412764c0-fd8e-11df-9019-835ae03a7500] [Core-UUID] = [7d858a18-fcb8-11df-8f82-835ae03a7500] [Channel-Read-Codec-Name] = [L16] [Caller-Channel-Name] = [skypopen/interface1] [Caller-Caller-ID-Number] = [niqizhi] [Event-Date-Timestamp] = [1291237357051788] [Channel-State-Number] = [4] [Event-Calling-Line-Number] = [2888] [chatname] = [#niqizhi/$abcdericunion;631dd843d9b3eb1a] [Event-Name] = [MESSAGE] [Content-Length] = [1] [subject] = [SIMPLE MESSAGE] [Caller-Caller-ID-Name] = [niqizhi] [from] = [niqizhi] [Caller-Dialplan] = [XML] [Caller-Channel-Hangup-Time] = [0] [id] = [5334] [Caller-Profile-Index] = [1] [Caller-Direction] = [inbound] [Caller-Username] = [skypopen] [Channel-Write-Codec-Name] = [L16] [Call-Direction] = [inbound] [Caller-Screen-Bit] = [true] [hint] = [niqizhi] [Caller-Privacy-Hide-Number] = [false] [Event-Date-Local] = [2010-12-01 21:02:37] [proto] = [skype] [Caller-Channel-Created-Time] = [1291237326468855] [Event-Calling-File] = [mod_skypopen.c] [Caller-Channel-Progress-Time] = [0] [Caller-Privacy-Hide-Name] = [false] [Channel-Write-Codec-Rate] = [16000] [Caller-Context] = [default] [Channel-Write-Codec-Bit-Rate] = [256000] [Presence-Call-Direction] = [inbound] [Caller-Profile-Created-Time] = [1291237326468855]

4 13

Difference Between "realm" and "challenge-realm" in sip_profiles
by Jerry Richards 21 Apr '11

21 Apr '11

Hello All, What is the difference between the parameters "realm" and "challenge-realm" in the conf/sip_profiles tree? Thanks, Jerry

2 1

bind_meta_app blocks DTMFs?
by Mariusz Czulada 15 Apr '11

15 Apr '11

Hi All, I'm trying to implement subconference feature, to allow some participants go (or rather "gosub") to a another conference room to discuss something then get back to the main conference. I use FreeSWITCH Version 1.0.head (hacked-20110112T172836Z). Bellow some configure extracts: >From conference.conf.xml: ... <caller-controls> ... <group name="just_exit"> <control action="hangup" digits="#"/> <control action="hangup" digits="1"/> <control action="mute" digits="0"/> </group> ... </caller-controls> ... <profiles> .. <profile name="confX_M"> ... <param name="caller-controls" value="just_exit"/> ... </profile> <profile name="confX_S"> ... <param name="caller-controls" value="just_exit"/> ... </profile> </profiles> ... >From dialplan (own) public/confX.conf.xml: ... <extension name="confX_join"> <condition field="destination_number" expression="^confX_join$"/> <condition field="${confX_num}" expression="^1(\d{4})$"> <action application="bind_meta_app" data="1 a s execute_extension::subX_1"/> <action application="bind_meta_app" data="2 a s execute_extension::subX_2"/> <action application="bind_meta_app" data="3 a s execute_extension::subX_3"/> <action application="conference" data="confX_${cpnfX_num}@confX_M"/> </condition> </extension> ... <extension name="subX_1"> <condition field="destination_number" expression="^subX_1$"> <action application="set" data="pass_rfc2833=true"/> <action application="conference" data="confX_${cpnfX_num}_1@confX_S"/> </condition> </extension> <extension name="subX_2"> <condition field="destination_number" expression="^subX_2$"> <action application="set" data="pass_rfc2833=true"/> <action application="conference" data="confX_${cpnfX_num}_2@confX_S"/> </condition> </extension> <extension name="subX_3"> <condition field="destination_number" expression="^subX_3$"> <action application="set" data="pass_rfc2833=true"/> <action application="conference" data="confX_${cpnfX_num}_3@confX_S"/> </condition> </extension> ... During connection user is first handled by IVR, where he enters conference number (assume: "1234") which is stored in "confX_num" variable. Then call is transfered to "confX_join". Here I assign actions for *1, *2 and *3 DTMF sequences then join main conference ("confX_1234_M"). When some user presses i.e. "*2" then he also enters subconf 2 ("confX_1234_2"). Those users attached to "confX_1234_2" are at the same time still attached also to "confX_1234_M", but found muted and deaf to other participants. Then, leaving subconference they will be back "alive" in master conference, which I tested by kicking them from "confX_1234_2" manually. Now my problem begins. Then user is on "confX_1234_M" dialing "#" forces user to leave conference, as defined in "just-exit" controls. But when user enters also "confX_1234_2" DTMF codes are no longer processed, neither by master conference nor by subconference. I set "pass_rfc2833=true" but it is not helpful. Did I missed to set something [1] in the dialplan or other config files, or [2] actually no DTMF codes can be processed while in "*2" leg? And if [2]==true: would it be possible to develop such DTMF handling? BTW: DTMFs are not processed while in subconference but if user is kicked off from subconf back to main conference, one can use DTMF codes again to (un)mute (0), join sub (*2) or leave (# or 1). TIA for your help or tips. Regards, Mariusz

4 5

FS HA
by Tihomir Culjaga 12 Apr '11

12 Apr '11

hello guys, i configured FS HA and looks like its trying to recover the call .. but the re-INVITE fails due to "wrong/missed" codec capability. freeswitch@internal> freeswitch@internal> sofia profile external siptrace on Enabled sip debugging on external freeswitch@internal> sofia profile internal siptrace on Enabled sip debugging on internal freeswitch@internal> freeswitch@internal> freeswitch@internal> freeswitch@internal> sofia recover Recovered 1 call(s) 2011-01-24 21:32:31.667404 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] freeswitch@internal> 2011-01-24 21:32:31.667404 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:32.726402 [NOTICE] switch_channel.c:669 New Channel sofia/external/385914392122(a)195.88.212.39[808b0a98-8928-4ca2-a320-8e026ba94018] *2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2354 Set Codec sofia/external/385914392122(a)195.88.212.39 PCMA/8000 20 ms 160 samples* 2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2594 AUDIO RTP [sofia/external/385914392122(a)195.88.212.39] 195.88.212.30 port 20092 -> 195.88.212.39 port 17750 codec: 8 ms: 20 2011-01-24 21:32:32.726402 [DEBUG] switch_rtp.c:1182 Starting timer [soft] 160 bytes per 20ms 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send payload to 101 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf receive payload to 101 2011-01-24 21:32:32.728288 [DEBUG] sofia_glue.c:2790 Set comfort noise payload to 13 2011-01-24 21:32:32.779414 [DEBUG] sofia_glue.c:4246 (sofia/external/ 385914392122(a)195.88.212.39) State Change CS_NEW -> CS_INIT 2011-01-24 21:32:32.779414 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.779414 [NOTICE] sofia_glue.c:4249 Resurrecting fallen channel sofia/external/385914392122(a)195.88.212.39 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_INIT 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:338 (sofia/external/385914392122(a)195.88.212.39) State INIT 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:83 sofia/external/ 385914392122(a)195.88.212.39 SOFIA INIT 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:114 (sofia/external/ 385914392122(a)195.88.212.39) State Change CS_INIT -> CS_EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:338 (sofia/external/385914392122(a)195.88.212.39) State INIT going to sleep 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:348 (sofia/external/385914392122(a)195.88.212.39) State EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] mod_sofia.c:226 sofia/external/ 385914392122(a)195.88.212.39 SOFIA EXECUTE 2011-01-24 21:32:32.780381 [DEBUG] switch_core_state_machine.c:157 sofia/external/385914392122(a)195.88.212.39 Standard EXECUTE EXECUTE sofia/external/385914392122(a)195.88.212.39 set(playback_delimiter=!) send 1029 bytes to udp/[195.88.212.39]:62342 at 20:32:32.781241: ------------------------------------------------------------------------ INVITE sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39>SIP/2.0 Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j Route: <sip:385914392122@195.88.212.39:62342;lr> Max-Forwards: 69 From: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 CSeq: 7614512 INVITE Contact: <sip:385914392122@195.88.212.30:5080> User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 168 X-FS-Support: update_display Remote-Party-ID: "38518880050" <sip:38518880050@195.88.212.30<sip%3A38518880050(a)195.88.212.30> >;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1295881060 1295881062 IN IP4 195.88.212.30 s=FreeSWITCH c=IN IP4 195.88.212.30 t=0 0* m=audio 20092 RTP/AVP 0 13* * a=rtpmap:13 CN/8000* a=ptime:20 ------------------------------------------------------------------------ 2011-01-24 21:32:32.781430 [DEBUG] sofia.c:4153 Channel sofia/external/ 385914392122(a)195.88.212.39 entering state [calling][0] recv 496 bytes from udp/[195.88.212.39]:5060 at 20:32:32.784077: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j From: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 Date: Mon, 24 Jan 2011 19:22:34 GMT Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 Server: Cisco-SIPGateway/IOS-12.x CSeq: 7614512 INVITE Allow-Events: telephone-event Remote-Party-ID: <sip:385914392122@195.88.212.39<sip%3A385914392122(a)195.88.212.39> >;party=called;screen=yes;privacy=off Content-Length: 0 ------------------------------------------------------------------------ recv 376 bytes from udp/[195.88.212.39]:5060 at 20:32:32.784195: ------------------------------------------------------------------------ SIP/2.0 488 Not Acceptable Media Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j From: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 Warning: 304 195.88.212.39 "Media Type(s) Unavailable" CSeq: 7614512 INVITE Content-Length: 0 ------------------------------------------------------------------------ send 395 bytes to udp/[195.88.212.39]:62342 at 20:32:32.784303: ------------------------------------------------------------------------ ACK sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39>SIP/2.0 Via: SIP/2.0/UDP 195.88.212.30:5080;rport;branch=z9hG4bKKDX31Z2Q71B3j Route: <sip:385914392122@195.88.212.39:62342;lr> Max-Forwards: 69 From: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r To: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 CSeq: 7614512 ACK Content-Length: 0 ------------------------------------------------------------------------ 2011-01-24 21:32:32.784397 [DEBUG] sofia.c:4153 Channel sofia/external/ 385914392122(a)195.88.212.39 entering state [terminated][488] 2011-01-24 21:32:32.784397 [NOTICE] sofia.c:4789 Hangup sofia/external/ 385914392122(a)195.88.212.39 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] 2011-01-24 21:32:32.784397 [DEBUG] switch_channel.c:2102 Send signal sofia/external/385914392122(a)195.88.212.39 [KILL] 2011-01-24 21:32:32.784397 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.852411 [DEBUG] mod_dptools.c:816 sofia/external/ 385914392122(a)195.88.212.39 SET [playback_delimiter]=[!] 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:348 (sofia/external/385914392122(a)195.88.212.39) State EXECUTE going to sleep 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_HANGUP 2011-01-24 21:32:32.853505 [DEBUG] switch_core_state_machine.c:499 (sofia/external/385914392122(a)195.88.212.39) State HANGUP 2011-01-24 21:32:32.861414 [DEBUG] mod_sofia.c:408 sofia/external/ 385914392122(a)195.88.212.39 Overriding SIP cause 488 with 488 from the other leg 2011-01-24 21:32:32.861414 [DEBUG] mod_sofia.c:414 Channel sofia/external/ 385914392122(a)195.88.212.39 hanging up, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:46 sofia/external/385914392122(a)195.88.212.39 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:499 (sofia/external/385914392122(a)195.88.212.39) State HANGUP going to sleep 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:333 (sofia/external/385914392122(a)195.88.212.39) State Change CS_HANGUP -> CS_REPORTING 2011-01-24 21:32:32.863454 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:314 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_REPORTING 2011-01-24 21:32:32.863454 [DEBUG] switch_core_state_machine.c:590 (sofia/external/385914392122(a)195.88.212.39) State REPORTING 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:53 sofia/external/385914392122(a)195.88.212.39 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:590 (sofia/external/385914392122(a)195.88.212.39) State REPORTING going to sleep 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:327 (sofia/external/385914392122(a)195.88.212.39) State Change CS_REPORTING -> CS_DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_session.c:1021 Send signal sofia/external/385914392122(a)195.88.212.39 [BREAK] 2011-01-24 21:32:32.864328 [DEBUG] switch_core_session.c:1164 Session 1 (sofia/external/385914392122(a)195.88.212.39) Locked, Waiting on external entities 2011-01-24 21:32:32.864328 [NOTICE] switch_core_session.c:1182 Session 1 (sofia/external/385914392122(a)195.88.212.39) Ended 2011-01-24 21:32:32.864328 [NOTICE] switch_core_session.c:1184 Close Channel sofia/external/385914392122(a)195.88.212.39 [CS_DESTROY] 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:428 (sofia/external/385914392122(a)195.88.212.39) Running State Change CS_DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:439 (sofia/external/385914392122(a)195.88.212.39) State DESTROY 2011-01-24 21:32:32.864328 [DEBUG] mod_sofia.c:341 sofia/external/ 385914392122(a)195.88.212.39 SOFIA DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:60 sofia/external/385914392122(a)195.88.212.39 Standard DESTROY 2011-01-24 21:32:32.864328 [DEBUG] switch_core_state_machine.c:439 (sofia/external/385914392122(a)195.88.212.39) State DESTROY going to sleep freeswitch@internal> freeswitch@internal> freeswitch@internal> 2011-01-24 21:32:51.813359 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:51.813359 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:52.810408 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:52.810408 [INFO] switch_odbc.c:210 The connection has been re-established 2011-01-24 21:32:53.817405 [CRIT] switch_odbc.c:205 The sql server is not responding for DSN COREFSdrv [STATE: HY000 CODE 7 ERROR: [unixODBC]Unknown error; FATAL: terminating connection due to administrator command ][176] 2011-01-24 21:32:53.817405 [INFO] switch_odbc.c:210 The connection has been re-established recv 432 bytes from udp/[195.88.212.39]:62342 at 20:33:06.045642: ------------------------------------------------------------------------ BYE sip:385914392122@195.88.212.30:5080 SIP/2.0 Via: SIP/2.0/UDP 195.88.212.39:5060;branch=z9hG4bK240FA From: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 To: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r Date: Mon, 24 Jan 2011 19:22:34 GMT Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 User-Agent: Cisco-SIPGateway/IOS-12.x Max-Forwards: 70 Timestamp: 1295896987 CSeq: 102 BYE Content-Length: 0 ------------------------------------------------------------------------ send 522 bytes to udp/[195.88.212.39]:5060 at 20:33:06.045858: ------------------------------------------------------------------------ SIP/2.0 481 Call Does Not Exist Via: SIP/2.0/UDP 195.88.212.39:5060;branch=z9hG4bK240FA From: <sip:385914392122@195.88.212.39 <sip%3A385914392122(a)195.88.212.39> >;tag=C4B0BE6C-1B8 To: <sip:38518880050@195.88.212.30 <sip%3A38518880050(a)195.88.212.30> >;tag=DFejDg1B59y9r Call-ID: 1785B58B-272611E0-8909D88B-B59C2BD1(a)195.88.212.39 CSeq: 102 BYE Timestamp: 1295896987 0.000191 User-Agent: FreeSWITCH-mod_sofia/1.0.6-svn-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Length: 0 ------------------------------------------------------------------------ freeswitch@internal> freeswitch@internal> my codec settings in vars.conf <X-PRE-PROCESS cmd="set" data="global_codec_prefs=PCMA,GSM"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMA,GSM"/> my codec settings in sip_profiles/* <param name="inbound-codec-prefs" value="$${global_codec_prefs}"/> <param name="outbound-codec-prefs" value="$${global_codec_prefs}"/> now, where the is FS picking up the codec list for the re-INVITE after "sofia recover" from the debug: 2011-01-24 21:32:32.726402 [DEBUG] sofia_glue.c:2354 Set Codec sofia/external/385914392122(a)195.88.212.39 PCMA/8000 20 ms 160 samples i can see sofia knows what codec is being used, but somehow its not sending it in re-INVITE. BTW: yea, i know, i know .. the version is a bit outdated but we can still make it working .. :)

7 19

time_test on Centos 5.5
by Louis Huppenbauer 09 Apr '11

09 Apr '11

Hi, I am testing FreeSWITCH on a Centos 5.5. The hardware is a 32 bit AMD Opteron 275. On the system I recognize a avg of 2000 if I run the time_test 1000 application. Currently I have no audio problems but I want to make sure that the system works well. There are 4 possible options: - Try to update the kernel to a newer one - Try to use debian. - Try to use the kernel-rt (realtime kernel from Centos) - Set some nice kernel options. Which? What do you think is the better solution? Thanks in advance. Kind regards, Louis

12 18

New FreeSWITCH IVR coming, but need HELP!
by Zac Wolfe 08 Apr '11

08 Apr '11

Hi guys, First some good news: we're finally close to releasing our free IVR Development platform SafiServer/SafiWorkshop (www.safisystems.com) with FreeSWITCH support! It's happening much later than we originally anticipated as we've been unexpectedly busy with contracting opportunities but I think it will be worth the wait. Currently everything is working fine with one minor exception: if the user-created script (we call them Saflets) doesn't explicitly hang up the call, the call will remain parked until the caller hangs up. Some details: In Asterisk we invoke our server-side scripting applications via the extensions.conf using the following syntax: exten = 1111,1,Agi(agi:// 192.168.0.10:3573/safletEngine.agi?saflet=project1/callflow1) Here '192.168.0.10' is the IP address of the SafiServer and project1/callflow1 identifies the Saflet to be executed. Asterisk creates a socket connection to the SafiServer and, once the socket is disconnected, the call proceeds to the next entry in the dialplan (typically 'hangup'). For FreeSWITCH, the process is slightly different. Currently, rather than create a separate socket connection for each incoming call, we're invoking an event that informs the SafiServer that there is a new incoming call. The event contains the contextual information including the Saflet name. For example: <extension name="9194"> <condition field="destination_number" expression="9194$"> <action inline="true" application="set" data="saficall=true"/> <action application="event" data="Event-Subclass=saficall::incoming,Event-Name=CUSTOM,saflet_project=test,saflet=flow1,new_saficall=true"/>  <action application="park" /> </condition> </extension> So once the event is fired, the call is parked to prevent further execution within the dialplan. From there on, SafiServer is controlling the call via Inbound Mod event socket. So this works perfectly, except that if the invoked Saflet doesn't explicitly hang-up the call it will remain parked until the caller hangs up. My question is, is there a better way to do this? Is there some better alternative to park in this case? Ideally I'd like to initiate a 'session' of some kind when the SafiServer is "controlling" the call and then exit that session as soon as the Saflet is complete, at which point the call would continue on to the next entry in the dialplan. I understand I could use Outbound sockets to achieve this but, as I mentioned, I'd like to avoid the overhead of a separate socket connection for each incoming call. I actually have a mod_saficall.c app that does basically the the same thing as I described in the dialplan entry. Perhaps there's something more I could do in code that would allow me to be notified when the session is complete. Here's the relevant code I have so far: switch_channel_t *channel = NULL; switch_event_t *event; const char *safiCallFlag = NULL; channel = switch_core_session_get_channel(session); safiCallFlag = switch_channel_get_variable(channel, "saficall"); if (!safiCallFlag) switch_channel_set_variable(channel, "saficall", "true"); if (switch_event_create_subclass(&event, SWITCH_EVENT_CUSTOM, "saficall::incoming") == SWITCH_STATUS_SUCCESS) { switch_event_add_header_string(event, SWITCH_STACK_BOTTOM, "new_saficall", safiCallFlag ? "false" : "true"); switch_channel_event_set_data(channel, event); switch_event_fire(&event); switch_ivr_park(session, NULL); } Any ideas you might have on this are welcome. Thanks, Zac Wolfe Safi Systems LLC www.safisystems.com

3 3

Invalid Application hash
by David Wafula 29 Mar '11

29 Mar '11

Hi all, Notice the last line in the log below when i dial 1001. This is from the latest git as of this morning. Any pointers? thanks. Dialplan: sofia/internal/1000(a)146.141.76.153 Regex (PASS) [Local_Extension] destination_number(1001) =~ /^(10[01][0-9])$/ break=on-false Dialplan: sofia/internal/1000(a)146.141.76.153 Action set(dialed_extension=1001) Dialplan: sofia/internal/1000(a)146.141.76.153 Action export(dialed_extension=1001) Dialplan: sofia/internal/1000(a)146.141.76.153 Action bind_meta_app(1 b s execute_extension::dx XML features) Dialplan: sofia/internal/1000(a)146.141.76.153 Action bind_meta_app(2 b s record_session::/usr/local/freeswitch/recordings/${caller_id_number}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav) Dialplan: sofia/internal/1000(a)146.141.76.153 Action bind_meta_app(3 b s execute_extension::cf XML features) Dialplan: sofia/internal/1000(a)146.141.76.153 Action set(ringback=${us-ring}) Dialplan: sofia/internal/1000(a)146.141.76.153 Action set(transfer_ringback=local_stream://moh) Dialplan: sofia/internal/1000(a)146.141.76.153 Action set(call_timeout=30) Dialplan: sofia/internal/1000(a)146.141.76.153 Action set(hangup_after_bridge=true) Dialplan: sofia/internal/1000(a)146.141.76.153 Action set(continue_on_fail=true) Dialplan: sofia/internal/1000(a)146.141.76.153 Action hash(insert/${domain_name}-call_return/${dialed_extension}/${caller_id_number}) Dialplan: sofia/internal/1000(a)146.141.76.153 Action hash(insert/${domain_name}-last_dial_ext/${dialed_extension}/${uuid}) Dialplan: sofia/internal/1000(a)146.141.76.153 Action set(called_party_callgroup=${user_data(${dialed_extension}@${domain_name} var callgroup)}) Dialplan: sofia/internal/1000(a)146.141.76.153 Action hash(insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}) Dialplan: sofia/internal/1000(a)146.141.76.153 Action bridge(user/${dialed_extension}@${domain_name}) Dialplan: sofia/internal/1000(a)146.141.76.153 Action answer() Dialplan: sofia/internal/1000(a)146.141.76.153 Action sleep(1000) Dialplan: sofia/internal/1000(a)146.141.76.153 Action voicemail(default ${domain_name} ${dialed_extension}) 2010-10-25 10:47:47.193206 [DEBUG] switch_core_state_machine.c:119 (sofia/internal/1000(a)146.141.76.153) State Change CS_ROUTING -> CS_EXECUTE 2010-10-25 10:47:47.193206 [DEBUG] switch_core_session.c:1057 Send signal sofia/internal/1000(a)146.141.76.153 [BREAK] 2010-10-25 10:47:47.193206 [DEBUG] switch_core_state_machine.c:345 (sofia/internal/1000(a)146.141.76.153) State ROUTING going to sleep 2010-10-25 10:47:47.193206 [DEBUG] switch_core_state_machine.c:318 (sofia/internal/1000(a)146.141.76.153) Running State Change CS_EXECUTE 2010-10-25 10:47:47.193206 [DEBUG] switch_core_state_machine.c:352 (sofia/internal/1000(a)146.141.76.153) State EXECUTE 2010-10-25 10:47:47.193206 [DEBUG] mod_sofia.c:239 sofia/internal/ 1000(a)146.141.76.153 SOFIA EXECUTE 2010-10-25 10:47:47.193206 [DEBUG] switch_core_state_machine.c:157 sofia/internal/1000(a)146.141.76.153 Standard EXECUTE EXECUTE sofia/internal/1000(a)146.141.76.153 set(open=true) 2010-10-25 10:47:47.193206 [DEBUG] mod_dptools.c:1028 sofia/internal/ 1000(a)146.141.76.153 SET [open]=[true] 2010-10-25 10:47:47.193206 [ERR] switch_core_session.c:1807 Invalid Application hash -- David Wafula

3 3

Re: [Freeswitch-users] outgoing callerid freetdm TDM400
by François Legal 28 Mar '11

28 Mar '11

That looks like the problem I had with my FXS ports sending CID not understood by european phones. In which country are you / what kind of analog phones are you using ? François On Wed, 8 Sep 2010 13:16:08 +1000, Brian May <brian(a)microcomaustralia.com.au> wrote: > On 8 September 2010 11:21, Moises Silva <moises.silva(a)gmail.com> wrote: >> Pastebin a debug log for a call. Also, before placing the call, create the >> directory /var/log/freetdm and then execute this in FreeSWITCH CLI: >> ftdm trace /var/log/freetdm/test <span> <chan> > > Hopefully I got this right ;-) > > <http://pastebin.com/dEXkkNaK> > > To me everything looks good in this listing. > > Not sure what I can do with the freetdm trace files...

4 18

IP Failover with Sofia Recover - not recovering?!
by Avi Marcus 15 Mar '11

15 Mar '11

I finally figured out how to get pacemaker to start profiles/trigger a sofia recover on moving the floating IP (but an FS crash it still can't handle) Anyway - I 1) set up odbc for the core, and mysql master-master replication, so I see calls & channels being logged in both 2) I set track calls in all the profiles So when I set it to transfer from one node to another, I'm kinda surprised I'm not getting a recovery of the calls. I do see that the DB has a hostname stored - "sip1" or "sip2" depending on where the call originated, but even if I change it manually, a sofia recover seems to ways say "no calls to recover" Am I missing something?! -Avi Marcus

4 12

Re: [Freeswitch-users] mod_callcenter features
by Rob Hutton 14 Mar '11

14 Mar '11

1. Try something like: reloadxml callcenter_config queue load|reload queue_name 2. I don't believe so. Hit Moc on the IRC channel. I am trying, also... -- Thanks, Rob On Friday 31 December 2010 00:32:46 Rajkumar K wrote: > Hi, > > 1. In mod_callcenter, there is no command like "callcenter_config queue add" > for adding queues dynamically. We need to configure it in > callcenter.conf.xml file and run "callcenter_config queue reload <queue > name>". So is there any other ways to add queues. > > 2. The mod_callcenter automatically bridges the call once it identifies the > available agent. But the requirement is to identify the available agent and > leave the bridge control to our dial plan. There we need to other operations > (like announcing caller name to agent) instead of bridging the call. > > regards > rajkumar k > > On Thu, Dec 30, 2010 at 6:12 PM, Rob Hutton <justlikeef(a)gmail.com> wrote: > > > Some of the API commands are on in the Wiki under the heading API: > > > > http://wiki.freeswitch.org/wiki/Mod_callcenter > > > > Everything starts with callcenter_config, so you can feel your way around > > the command line and everything is fairly self explanatory. > > > > What do you mean control the call flow? Can you give an example of what > > you are trying to accomplish? > > > > -- > > Thanks, > > Rob > > On Monday 27 December 2010 04:42:29 rajkumar wrote: > > > > > > Hi, > > > > > > I am developing an application with mod_callcenter. I need to know the > > > following about mod_callcenter. > > > > > > * Is it possible to add/update/delete the queue configurations > > dynamically > > > without using static xml configurations. > > > * How can I control the call flow (for playback message and recording) > > > before and after bridging the call. > > > > > > Thanks in advance > > > > > > regards > > > rajkumar k > > > > > >

2 1