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

[Freeswitch-dev] Cannot create outgoing channel type [error] cause: [FACILITY_NOT_SUBSCRIBED]
by Jerry Richards 24 Aug '09

24 Aug '09

Hello All, I am a Freeswitch Newbie and bringing up Freeswitch on my Windows XP machine for the first time using the Getting Started Guide. I can register three lines (1000, 1001, and 1002), but when I attempt to call one phone to the other I hear the operator say: "The person at extension 1000 is not available..." Also, the Freeswitch log shows: Cannot create outgoing channel type [error] cause: [FACILITY_NOT_SUBSCRIBED]Cannot create outgoing channel type [user] cause: [FACILITY_NOT_SUBSCRIBED] Does anyone know why I get this error? Best Regards, Jerry

1 0

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

21 Aug '09

Thanks Moises, I am keen to help. Implementing this would require architectural changes, which would be better made by people closer to and more experienced with freeswitch. Is there anything wrong with simply disabling DTMF suppression? All scenarios I can think of it is not going to matter if the in-band digits are passed through whole. The dirty hack is to comment out the memset line 2042 of zap_io.c, but something is also going on in the IVR bridge. I know line 261 and onwards in switch_ivr_bridge.c has something to do with it, but I do not understand the IVR stuff enough offer anything useful. As a test (not a fix!) commenting out the while loop on line 261 (in addition to the memset in zap_io.c) fixes the symptoms. Cheers -alex Moises Silva wrote: > I discussed with Mike Jerris some days ago, and as I pointed out we need > to be able to tell the duration of the DTMF. At this point libteletone > does not help with that (AFAIK), so we need to investigate and fix it. > Just haven't found the time to do it. Help is welcomed :-) > > On Thu, Aug 20, 2009 at 1:58 AM, Alex Green <alexg(a)etherstack.com > <mailto:alexg@etherstack.com>> wrote: > > Any thought on the email below? I would imagine that passing an analog > call through freeswitch is not too uncommon a use-case... > > > > 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 is 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> <mailto:moy@sangoma.com > <mailto:moy@sangoma.com>> > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev(a)lists.freeswitch.org > <mailto:FreeSWITCH-dev@lists.freeswitch.org> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > > > > -- > 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

1 0

[Freeswitch-dev] Debugging Question
by Gilles Depatie 20 Aug '09

20 Aug '09

Hi I'm new to Freeswitch environment, but I have attempted to build an executable where I could set breakpoints etc. I have followed the instructions on the wiki where I define the two environment vars CFLAGS and MOD_CFLAGS as "-g -ggdb" I then run configure which sets the gcc compile option parameters across all makefiles. I notice that during the compilation, those option are invoked for all source file that have produce output. I've also confirmed that the object files for a sample set of files are slightly larger when the compiler output has the options set than compiling without those two options. So I assume that debug symbols were produced when gcc is invoked with the debug option. What I see is that after I have run make install, the freeswitch executable is not any larger when debug symbols are requested than when it is not. In fact the opposite is true. Size with debug = "114804", WITHOUT debug = "114908" When I attempt to list files from the GDB command line, I get the following: "No source file named xxx.c" The only file I can list is "switch.c" , which is the one that has the main program. Here is my environment: VmWare Server 2.0 Red Hat 9 Linux, Kernel 2.6 FreeSwitch-1.0.4 gcc version 3.2.2 20030222 GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Any help would be appreciated Thanks Gilles Depatie

2 1

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

20 Aug '09

Any thought on the email below? I would imagine that passing an analog call through freeswitch is not too uncommon a use-case... > 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 is 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>

2 1

[Freeswitch-dev] Event Socket issue.
by hai lei 19 Aug '09

19 Aug '09

Hello, I am using Freeswitch to do some development work and encounter a problem with Event Socket. The configuration is: Freeswitch works as PBX. I also configure three softphones A, B and C. What I want is: 1. A call B. 2. B reject the call. 3. Freeswitch start conference involve A, B and C. What I did was: 1. Add perl script to the dialplan, so the perl script will be called after B reject the call from A. Worked fine. 2. In the script, I connected to localhost:8021 so the Freeswitch work in Inbound mode. Worked fine. 3. Then run $connection->execute to run "conference_set_auto_outcall" and "conference" command. Not worked. So I check the "parse_command" function in file "mod_event_socket.c", the following is what happened: Since I give the uuid to "$connection->execute" command, so FS doesn't care if it is Async mode or not. Actually FS just call function "switch_core_session_queue_private_event" to queue the event. Here is the problem, since B already reject the call, then nobody will call the function "switch_ivr_parse_event" to execute the command. I did try to add code to "parse_command" function to treat the Async and Sync mode differently when the uuid is provided. The conference was started successfully in Sync mode but since the "conference" application is blocked, my perl script was not able to move on since it was waiting for the "conference" to stop. If I choose "$connection->executeAsync", the commands were not run because of the reason I mentioned above. What is the proper solution for this? Thanks Hai Lei

1 0

[Freeswitch-dev] callerid
by Santosh 19 Aug '09

19 Aug '09

Hi, I am new to freeswitch and i need to fetch the callerid information.But my freeswitch is not showing me the callerid not even in the log.For the client I am using Linphone. How am I suppose to activate it.Your help would be appreciated. Regards, Santosh Disclaimer: The information contained in this e-mail and attachments if any are privileged and confidential and are intended for the individual(s) or entity(ies) named in this e-mail. If the reader or recipient is not the intended recipient, or employee or agent responsible for delivering to the intended recipient, you are hereby notified that dissemination, distribution or copying of this communication or attachments thereof is strictly prohibited. IF YOU RECEIVE this communication in error, please immediately notify the sender and return the original message.

3 2

[Freeswitch-dev] RFC 2198 (RTP Payload for Redundant Audio Data)
by Gilles Depatie 17 Aug '09

17 Aug '09

Hi Has anyone considered or attempted to implement this piece of functionality? As part of contract work for a customer using FreeSwitch, we have been asked to enhance FS to support this RFC. Any help or comments would be appreciated. Thanks Gilles

1 0

[Freeswitch-dev] Skypiax, Skype endpoint and trunk, robustness patch
by Giovanni Maruzzelli 14 Aug '09

14 Aug '09

Hi FreeSWITCHers, all the users of mod_skypiax are kindly requested to test the svn trunk 14519. It contains a lot of changes meant to add stability and robustness, toward a production environment. Let me know how your feelings, and please add to the Jira any possible bug/issue/etc. Thanks to you all, -giovanni Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618

1 1

[Freeswitch-dev] 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