- FreeSWITCH-dev - FreeSWITCH Mailing Lists

Answering a call...
by Kevin Snow 14 Aug '09

14 Aug '09

Guys, In my module (written in C), I have a call answering edge case that I think there must be an easier way than what I¹m doing. Or, more correctly, a right way to do this and I¹m currently not doing that. I have an active/established call. An incoming SIP call arrives and I send it off to switch_ivr_originate to ring my endpoints. Based on action outside of Freeswitch, I want to stop the ringing and have an endpoint from the established call answer this ringing call. I have a custom FS event generated to indicate this condition. In this event handler I want to take a channel from the active call and answer this incoming call. Here¹s what I¹m currently doing. In my event handler I¹m taking the endpoint of the active call and sending to a specific dialplan This dialplan has it call my C application. At this point the application is the session of the endpoint and it can get the session that¹s currently ringing. It gets the session of the ringing channel It uses switch_channel_answer to answer the ringing channel. Then it uses switch_ivr_uuid_bridge to bridge these two endpoints. Seems simple enough but it¹s not working. The problems I have are: Doing this seems to make the switch_ivr_originate that was ringing the endpoints fail with ORIGINATOR_CANCEL. I special case this but it leads me to believe I¹m going about this the wrong way. I¹m not trying to cancel it, I want to answer it. I¹m not breaking the bridge of the original established call. That too seems wrong. I think I should be doing something there but it¹s not clear what. Is there a better way to handle this? Thanks Kevin Snow

6 11

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

14 Aug '09

Moises Silva wrote: > 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). > > > you mean libteletone detects it but ZAP_EVENT_DTMF is not launched? the > next test should be in zap_channel_read, which uses teletone_dtmf_detect > and teletone_dtmf_get to retrieve DTMF and queue the DTMF, there you > will be able to find out what is going on. > On doing more testing, I have to retract that statement. I can confirm that the EVENT_DTMF is always correctly returned when using software detection, but not when using hardware DTMF detection (regardless of PRI or analog). > > 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. > > > Indeed ZAP_CHANNEL_SUPRESS_DTMF causes zap_channel_read to memset the > read data each time a digit hit is found. The problem is that there is > no DTMF_START and DTMF_END events and the DTMF length is lost, we just > have a plain DTMF event for the start. Not sure about how to use > libteletone to detect the DTMF end though. > DTMF suppression is mangling the digits. It took me a while to get to the bottom of this, but it turns out to be very easy to reproduce. Take Freeswitch with an FXS port and a handset. Dial 1000 on the handset and answer the call on a SIP client. Now hold down a digit. You will notice that the digit has a wobble at the start. This is the symptom. Commenting out the DTMF suppression code, changes the behaviour but does not fix the problem. This is what baffled me for a while. I wrote some trivial code that bridges two analog channels by doing a zap_channel_read/write() from one to the other. Commenting out the memset() on line 2042 of zap_io.c produced perfect digits while uncommenting it produced the wobble. The obvious conclusion was that the dodgy digit suppression is being attempted somewhere else (like the SIP side?) and thus the wobble is being introduced at more than one place. This also explains why I (non scientifically) noticed that the more times the call passed through Freeswitch the more incorrectly recognised digits were reported at the final point. I imagine that a solution might be to just turn off DTMF digit suppression by default until it is fixed. Cheers, -alex > Anthony, Mike? care to comment about this one? > > -- > 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>

1 0

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

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

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

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

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

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 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