August 2009 - freeswitch-dev@lists.freeswitch.org

Re: [Freeswitch-dev] Detecting in-band DTMF Digits in Openzap?
by Alex Green 13 Aug '09

13 Aug '09

Ok, I think I have gotten to the bottom of it: 1.: Using zap_channel_dequeue_dtmf() correctly identifies digits for both in-band PRI and analog. 2.: Setting an event callback and waiting for ZAP_EVENT_DTMF works for in-band digits on a PRI channel. 3.: Potential bug: As suggested by Moises, adding extra logging in libteletone_detect.c shows that digits were detected, but the ZAP_EVENT_DTMF events were *not* sent back for an analog channel (I am using an Openvox A800p, but it looks to be the same for all analog cards). 4.: Potential bug: DTMF digit detection *eats some audio* each time a digit is detected. If the device is connected directly to free switch this is not a problem. If a device makes a call through freeswitch (to let's say phone banking) a digit that is held down may be detected as 3 digits (sometimes more) due to the consumed audio. This can be heard on the other side of freeswitch as a start-stop at the start of the DTMF. Any thoughts? Cheers -alex Moises Silva wrote: > On Tue, Aug 11, 2009 at 1:17 AM, Alex Green <alexg(a)etherstack.com > <mailto:alexg@etherstack.com>> wrote: > > Thanks Moises, do I need to do a flush_dtmf() or set values for DTMF > on/off period, or anything else? > > > I think default on/off times are good enough, but I suppose you may have > to play with it. As of flushing, sounds like a good idea to do when the > call starts, but that depends on your applications, if you are certain > of consuming all DTMF always, then is not needed. > > Are you using hw dtmf? are you using Sangoma boards? > > I noticed that openzap behavior will be different from an API point of > view when using hardware DTMF than when using software DTMF, since the > callbacks (for span and channel) are currently not available when using > hardware DTMF. That sounds like a bug to me, the behavior should be > available regardless of the backend system used for DTMF. I will fix > that asap. > > > zap_channel_dequeue_dtmf() correctly identifies the digit, but if the > digit is held down it is detected more than once. I am using a frame > size of 160 for the read. > > > More than once like in twice? 3 times, 4 times? ad infinitum if the > digit is hold? I'd need to debug to try to figure out where that comes > from. If you are using hardware dtmf in wanpipe boards you can go to > src/ozmod/ozmod_wanpipe/ozmod_wanpipe.c and search for > WP_TDMAPI_EVENT_DTMF, then uncomment the log line there to see if the > digit is detected twice by the drivers. > > If using software DTMF, some logging in zap_channel_read when calling > teletone_dtmf_detect() can be added to check if its detecting it twice. > > -- > Moises Silva > Software Developer > Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R > 9T3 Canada > t. 1 905 474 1990 x 128 | e. moy(a)sangoma.com <mailto:moy@sangoma.com> > > > ------------------------------------------------------------------------ > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org

2 1

[Freeswitch-dev] How to contribute ?
by Dome Charoenyost 13 Aug '09

13 Aug '09

Dear all, I want to contribute mod_say_th (Say for Thai language). how to send patch ? Dome C.

5 4

[Freeswitch-dev] bgapi takes 20ms to return job-id
by Paweł Pierścionek 11 Aug '09

11 Aug '09

Hi, Any ideas why most calls to bgapi take 20ms (on avg) on my idle quad core FC10 box doing a single transaction at a time ? Can do 300 call per second on that box using SIPP but when a single process tries to control my FS instance using a single ESL socket than 95% of the bgapi calls return job-id in 20ms. The rest takes under a millisecond as it should. Is it possible that thread creation takes 20ms or that the job thread itself gets it's CPU timeslice before the job-id gets sent out (hardly possible with 4 CPU threads) ? I have not done any benchmarking yet to see where the real delay is - but it is visible on the loopback interface and limits the performance of my inbound socket app. a fast one: bgapi uuid_displace fca427df-a8b0-4aff-8041-e328691dea3d start tone_stream://v=-10;%(150,100,400,450);loops=2 ### T +0.001165 127.0.0.1:18022 -> 127.0.0.1:44944 [AP] Content-Type: command/reply Reply-Text: +OK Job-UUID: 73f5ac5f-f3b5-44f0-a839-1b5c785b3ae7 Job-UUID: 73f5ac5f-f3b5-44f0-a839-1b5c785b3ae7 a 20ms delay for similar calls bgapi uuid_displace 380e9f71-f6f2-3b94-3ae0-bc6437bed887 start tone_stream://v=-10;%(150,100,400,450);loops=2 ### T +0.020224 127.0.0.1:18022 -> 127.0.0.1:44944 [AP] Content-Type: command/reply Reply-Text: +OK Job-UUID: a7bc6bc9-b7ed-4c8b-a55d-61a48427ceb9 Job-UUID: a7bc6bc9-b7ed-4c8b-a55d-61a48427ceb9 Pawel,

2 2

Re: [Freeswitch-dev] Detecting in-band DTMF Digits in Openzap?
by Alex Green 11 Aug '09

11 Aug '09

Thanks Moises, do I need to do a flush_dtmf() or set values for DTMF on/off period, or anything else? zap_channel_dequeue_dtmf() correctly identifies the digit, but if the digit is held down it is detected more than once. I am using a frame size of 160 for the read. Thanks again, -alex Moises Silva wrote: > On Mon, Aug 10, 2009 at 10:26 PM, Alex Green <alexg(a)etherstack.com > <mailto:alexg@etherstack.com>> wrote: > > For FXO I switch back to the dialtone state and collect the digits via > the ZAP_SIGEVENT_COLLECTED_DIGIT call back (which is a little bit ugly > and does not allow dial ahead, but it works). > > > Sounds way too ugly, I don't think you should be doing that. > > > DIALTONE' is printed if you try). Openzap must be able to detect digits > during a call, but I am having trouble figuring out how. > > ie. How do you use Openzap to detect in-band DTMF digits during a call? > > > Take a look at mod_openzap/mod_openzap.c, on_clear_channel_signal() > > It seem to me you should do the same. > > zap_channel_command(sigmsg->channel, ZAP_COMMAND_ENABLE_DTMF_DETECT, > &tt); where tt = ZAP_TONE_DTMF and sigmsg->channel is the zap_channel_t > > That will enable the DTMF detection feature in the channel (either in > software or hardware if its available). > > After enabling that feature, you can use zap_channel_dequeue_dtmf(zchan, > dtmf, sizeof(dtmf)); to dequeue DTMF after calling zap_channel_read(), > since there is where dtmf (if any) is enqueued. Check zap_channel_read > so you can see how the DTMF is detected and enqueued. > > If you don't want to call zap_channel_dequeue_dtmf on each read (or you > can't), then register an event callback for the span with > zap_span_set_event_callback(), then your code will be called with > ZAP_EVENT_DTMF when dtmf is received in any channel on that span. > > Hope that helps, > > -- > Moises Silva > Software Developer > Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R > 9T3 Canada > t. 1 905 474 1990 x 128 | e. moy(a)sangoma.com <mailto:moy@sangoma.com> > > > ------------------------------------------------------------------------ > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org

2 1

[Freeswitch-dev] Detecting in-band DTMF Digits in Openzap?
by Alex Green 11 Aug '09

11 Aug '09

For FXO I switch back to the dialtone state and collect the digits via the ZAP_SIGEVENT_COLLECTED_DIGIT call back (which is a little bit ugly and does not allow dial ahead, but it works). However, for the E1 PRI card there is no dialtone state, which makes sense as the digits are sent over the D-Channel ('VETO Changing state on 1:1 from UP to DIALTONE' is printed if you try). Openzap must be able to detect digits during a call, but I am having trouble figuring out how. ie. How do you use Openzap to detect in-band DTMF digits during a call? Thanks, -alex

2 1

[Freeswitch-dev] Invalid rpaths + fix (1.0.4)
by Patrick 11 Aug '09

11 Aug '09

Hi, I was reworking the freeswitch.spec file to make it build an RPM on Fedora 11 and noticed the following: [..snip a gazillion previous ones..] ERROR 0002: file '/opt/freeswitch/mod/mod_sndfile.so' contains an invalid rpath '/opt/freeswitch/mod' in [/opt/freeswitch/lib64:/opt/freeswitch/mod] [..snip a gazillion more..] To solve this issue I had to add in the spec file after configure the following lines: # kill rpath madness in the top level libtool sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool # and fix it in the libtool in libs/openzap too sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libs/openzap/libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libs/openzap/libtool Maybe this could be done on libtool in trunk? If I need to report this in Jira please let me know. Regards, Patrick

3 6

[Freeswitch-dev] Problem with RTP auto_flush code and hot_socket
by Cooper Xu 08 Aug '09

08 Aug '09

Hi, In our load test, we found that the new RTP auto_flush and hot_socket code after version 1.04 seems to cause voice quality problem. We were stress testing Freeswitch with 250 channels using codec G.711u and iLBC. The RTP auto_flush appeared to be trigged very frequently. Because our system is under load and socket buffer for RTP stream sometimes accumulated a few packets before the channel can handle it. When this happened, the RTP auto_flush and hot_socket mechanism seemed sending those accumulated packets in a very short interval. However after this burst, the RTP stream receiving will wait for 80-100ms before receiving and sending another RTP packet. To find out why this can happen, We looked at the RTP part of Freeswitch code and found that inside the RTP read, during auto RTP flush, it will call switch_core_timer_sync() function. This will add 3 to the timer reference count and the next switch_core_timer_next() call will add another 1 to timer reference. This caused the next RTP receiving being delayed 80-100ms. This 80-100ms delay for RTP receiving caused 4-5 packets being accumulated in socket buffer again. And it will soon trigger another auto_flush for RTP stream. As the result, we saw a lot of short burst in the RTP stream, which caused voice quality problem.

2 1

[Freeswitch-dev] FreeSWITCH 1.0.4 Release Announcement
by Michael Collins 07 Aug '09

07 Aug '09

We are happy to announce the official release of FreeSWITCH 1.0.4! Please visit this link <http://digg.com/d3zt5X> to Digg and read the story, and then spread the word! Thanks for being such a great community! -Michael

2 1

[Freeswitch-dev] ESL UUIDs
by João Mesquita 06 Aug '09

06 Aug '09

What is the difference between a Core-UUID and Unique-ID? Wiki page states that all events should have a Core-UUID, but when log 7 sends events that do not have a Core-UUID. I am looking for something that can be a hash key to all events sent from a server. I don't have a problem using Unique-ID, but that is not present on all events (obviously). jmesquita

3 4

[Freeswitch-dev] freepbx for freeswitch
by Giovanni Maruzzelli 05 Aug '09

05 Aug '09

Yay! http://freepbx.org/news/2009-08-04/freepbx-v3-come-help-us-shape-the-future Darren Schreiber has made the announcement and is doinng a presentation of FreePBX V3 right now at www.cluecon.com.

1 0