- FreeSWITCH-users - FreeSWITCH Mailing Lists

Re: [Freeswitch-users] Problems with CURL_XML and bridging ?
by Bob Smith 14 Jan '12

14 Jan '12

Actually, you're quite right. I've gone back and double checked. Does not work with static XML. Same behaviour... transfer works, bridge fails. However I can definitely originate a call from the CLI over the same route ..... "originate sofia/gateway/mygate/12345678 &park" works great. That's what's really bugging me, if I can CLI originate to that number, if I can call that PSTN number from my FreeSwitch softphone, why on earth can't i do this simple bridge ! ;-( >So doing the bridge to the same number with static XML worked, but when > bridging to the exact same endpoint with xml_curl you're getting a 503?

1 0

Problems with CURL_XML and bridging ?
by Bob Smith 14 Jan '12

14 Jan '12

Hi, I'm trying to get a basic CURL XML going that will dynamically manage DDI numbers as part of a database-driven follow me function. My database generates the following output : <?xml version="1.0" encoding="UTF-8" standalone="no"?> <document type="freeswitch/xml"> <section name="dialplan" description="CURL Dialplan Result"> <context name="public"> <extension name="curl_dialplan"><condition field="destination_number" expression="^(87654321)$"> <action application="set" data="domain_name=my.domain.name"/>  <action application="transfer" data="1000 XML default"/> </condition> </extension> </context> </section> </document> When the action is "transfer", everything works great. However when "transfer" is the commented one and bridge is active nothing works. I have tried adding <action application="set" data="hangup_after_bridge=true"/> when bridging, but that has no effect either. Here's what it looks like when trying to bridge : 2012-01-14 15:19:24.136494 [INFO] mod_dialplan_xml.c:481 Processing 12345678 <12345678>->87654321 in context public Dialplan: sofia/internal/12345678(a)192.168.1.134 parsing [public->curl_dialplan] continue=false Dialplan: sofia/internal/12345678(a)192.168.1.134 Regex (PASS) [curl_dialplan] destination_number(87654321) =~ /^(87654321)$/ break=on-false Dialplan: sofia/internal/12345678(a)192.168.1.134 Action set(domain_name=my.domain.name) Dialplan: sofia/internal/12345678(a)192.168.1.134 Action bridge(sofia/gateway/mygate/12345678) 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:154 (sofia/internal/12345678(a)192.168.1.134) State Change CS_ROUTING -> CS_EXECUTE 2012-01-14 15:19:24.176505 [DEBUG] switch_core_session.c:1180 Send signal sofia/internal/12345678(a)192.168.1.134 [BREAK] 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:410 (sofia/internal/12345678(a)192.168.1.134) State ROUTING going to sleep 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:362 (sofia/internal/12345678(a)192.168.1.134) Running State Change CS_EXECUTE 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:417 (sofia/internal/12345678(a)192.168.1.134) State EXECUTE 2012-01-14 15:19:24.176505 [DEBUG] mod_sofia.c:241 sofia/internal/12345678(a)192.168.1.134 SOFIA EXECUTE 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:192 sofia/internal/12345678(a)192.168.1.134 Standard EXECUTE EXECUTE sofia/internal/12345678(a)192.168.1.134 set(domain_name=my.domain.name) 2012-01-14 15:19:24.176505 [DEBUG] mod_dptools.c:1281 sofia/internal/12345678(a)192.168.1.134 SET [domain_name]=[my.domain.name] EXECUTE sofia/internal/12345678(a)192.168.1.134 bridge(sofia/gateway/mygate/12345678) 2012-01-14 15:19:24.176505 [DEBUG] switch_ivr_originate.c:1884 Parsing global variables 2012-01-14 15:19:24.176505 [NOTICE] switch_channel.c:930 New Channel sofia/external/12345678 [2408b0f2-3ec3-11e1-afaf-89a010d7e66c] 2012-01-14 15:19:24.176505 [DEBUG] mod_sofia.c:4674 (sofia/external/12345678) State Change CS_NEW -> CS_INIT 2012-01-14 15:19:24.176505 [DEBUG] switch_core_session.c:1180 Send signal sofia/external/12345678 [BREAK] 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:362 (sofia/external/12345678) Running State Change CS_INIT 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:401 (sofia/external/12345678) State INIT 2012-01-14 15:19:24.176505 [DEBUG] mod_sofia.c:85 sofia/external/12345678 SOFIA INIT 2012-01-14 15:19:24.176505 [DEBUG] mod_sofia.c:125 (sofia/external/12345678) State Change CS_INIT -> CS_ROUTING 2012-01-14 15:19:24.176505 [DEBUG] switch_core_session.c:1180 Send signal sofia/external/12345678 [BREAK] 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:401 (sofia/external/12345678) State INIT going to sleep 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:362 (sofia/external/12345678) Running State Change CS_ROUTING 2012-01-14 15:19:24.176505 [DEBUG] switch_channel.c:1890 (sofia/external/12345678) Callstate Change DOWN -> RINGING 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:410 (sofia/external/12345678) State ROUTING 2012-01-14 15:19:24.176505 [DEBUG] mod_sofia.c:148 sofia/external/12345678 SOFIA ROUTING 2012-01-14 15:19:24.176505 [DEBUG] switch_ivr_originate.c:66 (sofia/external/12345678) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2012-01-14 15:19:24.176505 [DEBUG] switch_core_session.c:1180 Send signal sofia/external/12345678 [BREAK] 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:410 (sofia/external/12345678) State ROUTING going to sleep 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:362 (sofia/external/12345678) Running State Change CS_CONSUME_MEDIA 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:429 (sofia/external/12345678) State CONSUME_MEDIA 2012-01-14 15:19:24.176505 [DEBUG] switch_core_state_machine.c:429 (sofia/external/12345678) State CONSUME_MEDIA going to sleep 2012-01-14 15:19:24.176505 [DEBUG] switch_core_session.c:875 Send signal sofia/external/12345678 [BREAK] 2012-01-14 15:19:24.176505 [DEBUG] sofia.c:5494 Channel sofia/external/12345678 entering state [calling][0] 2012-01-14 15:19:24.316487 [DEBUG] switch_core_session.c:875 Send signal sofia/external/12345678 [BREAK] 2012-01-14 15:19:24.316487 [DEBUG] switch_core_session.c:875 Send signal sofia/external/12345678 [BREAK] 2012-01-14 15:19:24.316487 [DEBUG] switch_core_session.c:875 Send signal sofia/external/12345678 [BREAK] 2012-01-14 15:19:24.316487 [DEBUG] sofia.c:5494 Channel sofia/external/12345678 entering state [terminated][503] 2012-01-14 15:19:24.316487 [DEBUG] switch_channel.c:2852 (sofia/external/12345678) Callstate Change RINGING -> HANGUP 2012-01-14 15:19:24.316487 [NOTICE] sofia.c:6258 Hangup sofia/external/12345678 [CS_CONSUME_MEDIA] [NORMAL_TEMPORARY_FAILURE]

3 4

Measuring the call quality
by Nicolás Menoni 14 Jan '12

14 Jan '12

Hello, Is there a tool for measure the call quality and take the statistics? The idea is take statistics in packet loss, jitter, delay, etc., per each call and save these in a DB. Thank you!

4 3

Unable to get rtp and pre_answer working while looping back via sip (Sofia Bug or I miss something?)
by Anton VG 14 Jan '12

14 Jan '12

Hi Gentlemen! Broke my brain trying to force my FS, controlled by ESL inbound to give me early media in indirect calling scheme. Please help: When call comes, in some cases, I do not just originate destination, but need to dial on behalf of another user (not the user which originally dialed in). For this I dial back my FS box via sip, setting apropriate SIP variables, so FS originates another call, as if the user I need originated a call, and so so I have extra CDR and so on. BUT there is a problem:If I dial like this, - EARLY MEDIA does not work. 180 and 183 are send correctly and in time. however, all works if I dial directly (dialing schemes are given below) tcpdumping shows that there is no RTP coming to my FS box when I dial doing one loop. BUT - RTP appears immediately after answering the inbound channel: (regardless if dialed destination answered or not) - so dialing without the loop and doing pre_answer - I get RTP OK, if after a looped call i do pre_answer - I do not get RTP Also, RTP appears immediately if instead pre_answer I do answer on call 2! My dialing schemes: **** Direct mode ********** Incoming call (UUID1)-> PARK make UUID2 originate (using uuid2) sofia/gateway/some_gateway &park Listen for CHANNEL_PROGRESS_MEDIA and do pre_answer(UUID1) uuid_bridge(UUID1,UUID2) ******** in a looped mode ******* Thread 1 _INCOMING CALL_ (call1) Incoming call -> PARK make UUID2 originate (using uuid2) sofia/gateway/MY_IP_ADDRESS/another_user &park Listen for CHANNEL_PROGRESS_MEDIA and do pre_answer(UUID1) uuid_bridge(UUID1,UUID2) Thread 2 _OUTGOING_ (call 2) incoming call 2 (UUID3) (comes from call above) -> PARK make UUID4 originate (using uuid4) sofia/gateway/some_gateway &park Listen for CHANNEL_PROGRESS_MEDIA and do pre_answer(UUID3) uuid_bridge(UUID3,UUID4) Any clue? Regards, Anton

1 2

stun.freeswitch.org stun service down
by Brian Foster 14 Jan '12

14 Jan '12

Stun server is down at stun.freeswitch.org. I don't know who runs it but probably needs a service restart. Thanks! -BD

1 0

Gemeinschaft 4.0 (FreeSWITCH based) released
by Thomas Mueller 14 Jan '12

14 Jan '12

hi all maybe interesting for german / swiss users: Gemeinschaft 4.0, which uses FreeSWITCH, was released yesterday. http://groups.google.com/group/gemeinschaft-announce/browse_thread/thread/9… (german only). - Thomas

7 14

Are you using mod_httapi
by Michael Collins 14 Jan '12

14 Jan '12

Hello all! I know that many of you already know about mod_httapi. I am collecting examples and experiences from people who have had a chance to try it out. If you are using mod_httapi, even just for testing/tinkering, please contact me off list. Thanks! -Michael

1 0

Re: [Freeswitch-users] valet_park timeout
by Bob Smith 13 Jan '12

13 Jan '12

Michael, Permit me to perhaps expand a little on why I said what I did : 1. As a newbie to Freeswitch, it is right and proper that I take the time to review the available documentation (including purchasing the eBook in my case). The wiki documentation is severely lacking... some of it is out of date, a lot of it is very sparse, and there many un-necessary and unprofessional comments embedded in it (e.g. "???What is it acknowledging???", "What does this do ???" etc.). I have been spending many frustrating hours trying to educate myself in the mysterious FreeSwitch through the wiki and eBooks. Why ? Because I consider it the correct approach as opposed to littering the "freeswitch-users" list with a ton of newbie questions. 2. Building on the point above, surely you should be encouraging ease of adoption by a new community of users. Uses who will no doubt eventually end up contributing to the project as their experience with Freeswitch grows, and their time permits. It is not exactly fair or reasonable to expect newbies to dig around the source code in order to uncover useful functions which are undocumented, but have long been stable. Particularly, if like me, their background is not in C programming. 3. I was not asking the developers to write a book each time they code a new feature. Even just a two column table (function/variable/etc + one or two phrase description of function/variable/etc.) would be better than the old, out of date Wiki of today. The developers are the ones best placed to know when a feature is (a) introduced and (b) becomes stable enough in the code tree that they are happy with it. As you well know, half of a coders job is documenting .... uncommented code is sloppy, undocumented software is unusable. As developers, you should be proud of your work, proud of all the new features you're introducing, and the existing features you are enhancing. So surely you should be blowing your trumpet by even modestly documenting your new work by a new phrase or two in the wiki ? Take my example of valet_park timeouts …. I spent much time trying to search through the lists, more time digging fruitlessly through the wiki and the eBook in search of the faintest trace of documentation of the new variables introduced. I tried poking through the source code, but being unfamiliar with (a) C and (b) the FreeSwitch tree, I couldn't really comprehend what was going on. So I ask on Freeswitch-Users and get a stupid answer that says "LOOK CLOSELY" (little did the poster know just how much time I had expended "looking closely" !!!) … I spent days looking closely, days which could have been avoided if the developers took 2 minutes to add 4 lines to the Wiki just listing and ever so briefly describing the new variables ! Everyone is entitled to their own opinion, of course, but I suspect this is one area where ours may vary ! B

4 3

audo sync issues with record_session to mp3
by Tom Parrott 13 Jan '12

13 Jan '12

Hi, We are running a cluster of 3 SIP servers all running Freeswitch. Each call is recorded using the record_session application to record to mp3 files using mod_shout. Longer calls, after about 10 minutes start to introduce sync issues between the A-leg and the B-leg. We are running record_session on the A-leg, and it seems to get ahead of the B-leg. For example the caller on the A-leg will be heard to answer a question whilst the person on the B-leg is asking it. I am aware that recording to .mp3 can use additional resources, but these are quad core servers with 4GB of ram and they are only doing around 10 concurrent calls each. Additionally I have seen others experiencing these issues with Wav files too: http://lists.freeswitch.org/pipermail/freeswitch-users/2010-July/060107.html I am using the git head version from Tue 11 Oct 2011. I have also tried turning off enable_file_write_buffering on the A-leg however this makes no difference either. Does anyone have any suggestions? Thanks

6 6

Empty WAV file recorded
by Hynek Cihlar 13 Jan '12

13 Jan '12

Hi all, an attempt to uuid_record ends with wav file with no data only header. ct The scenario is following: 0. FS <---> ESL app 1. Bridge is established on one incoming and one originated channel. One channel hangs up. 2. uuid_record start is issued on the active channel. 3. uuid_record stop is issued on the active channel. 4. The result is a wav file with always the same length of 44 bytes. When recording to mp3, the file is always correctly created. Any idea how to diagnose the problem? Hynek

3 4