Hi, Yes, I see the race now. Locking in the analog module is, in my opinion, lacking a refactoring, but I've tried to not touch much the analog module since I don't have much time to test it.
Before showing you where the problem is, here is a brief explanation of the process for an outgoing call. When FreeSWITCH wants to place a call it will call the .outgoing_channel function pointer of the FreeTDM module, which points to channel_outgoing_channel in mod_freetdm.c line 1037. That function is called in the caller thread (assuming there is a caller), the caller may be a SIP endpoint, other analog channel or whatever technology FS supports. At this point ftdm_channel_call_place() will be called, which is pretty much a wrapper for the FTDM signaling module outgoing_call function pointer (span->outgoing_call) that is set depending on the signaling for that channel. In this case is analog_fxs_outgoing_call(). In the case of analog, this spawns a new thread, meaning the analog stack spawns a thread per call (where all current ISDN stacks have just 1 thread per span handling the signaling for all calls in that span at once). The problem right here is that ftdm_channel_open_chan is using ftdm_mutex_trylock(), and with the new code, the channel sometimes will be locked by a few microseconds by the outgoing routine, which, if at that particular moment ftdm_channel_open_chan is called by the service thread (ftdm_analog_channel_run), it will fail the whole call. This is legacy code I have leaved pretty much untouched, but I think I will get rid of it and use a regular ftdm_mutex_lock(). You can give that a try (just change trylock for lock ... or wait for me, I am cooking some changes now that are cleaning up some old and duplicated code when opening channels/requesting channels, should be ready tomorrow. Moises Silva Senior Software Engineer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. m...@sangoma.com On Mon, Jun 7, 2010 at 4:17 PM, <de...@thom.fr.eu.org> wrote: > I’m in the process of testing the patch, and I have some troubles with > FXS now. > > > > When bridging a call onto an FXS channel, the bridge fails. What seem to > happen is the lock acquired in ftmod_analog.c line 83 is not released (seems > it is not) before ftdm_analog_channel_run calls ftdm_channel_open_chan which > in turn tries to acquire and fails the same lock. > > > > If I add a 500ms delay (ftdm_sleep) at the entrance of > ftdm_analog_channel_run, the problem disappears. > > There seem to be a race condition here, but as I have no idea how threads > are scheduled (nor within mod_freetdm neither in overall freeswitch) this is > beyond my skills. However (I get the same kind of scheduling problems when > trying to thread the MWI function) I’d be glad to learn how that works, so > if you have any pointers… > > > > François > > > > > > *De :* freeswitch-dev-boun...@lists.freeswitch.org [mailto: > freeswitch-dev-boun...@lists.freeswitch.org] *De la part de* Moises Silva > *Envoyé :* jeudi 3 juin 2010 23:35 > > *À :* freeswitch-dev@lists.freeswitch.org > *Objet :* Re: [Freeswitch-dev] FXS bridged on FXO ports and DTMF > > > > Something is f'd up there badly. I cannot reproduce this in my A200. > > Can you give me more details of how are you wiring things up? > > Also do "git pull", I just improved the DTMF logging to aid in in > debugging. Reproduce the problem and pastebin the resulting logs. > > Regarding your MWI patch. I added some comments on JIRA. > > Moises Silva > Senior Software Engineer > Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R > 9T3 Canada > t. 1 905 474 1990 x 128 | e. m...@sangoma.com > > On Thu, Jun 3, 2010 at 6:46 AM, François Legal <de...@thom.fr.eu.org> > wrote: > > So now using latest git and wanpipe is even worse compared to snapshot from > last week. freetdm now also detects and queue the DTMF from the dialed > number. > > The new patch is available. > > On Wed, 2 Jun 2010 16:26:49 -0400, Moises Silva <moises.si...@gmail.com> > wrote: > > I'm going to test this DTMF scenario now and let you know. > > In the meantime, would it be much to ask a patch that I can apply using git > apply?? The patch still fails to apply using git, I see you are still using > svn, try git plz. > > The code looks good though :-) > > Moises Silva > Senior Software Engineer > Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R > 9T3 Canada > t. 1 905 474 1990 x 128 | e. m...@sangoma.com > > On Wed, Jun 2, 2010 at 4:19 PM, <de...@thom.fr.eu.org> wrote: > > I just updated to 3.5.11 and the result is the same. > > > > *De :* freeswitch-dev-boun...@lists.freeswitch.org [mailto: > freeswitch-dev-boun...@lists.freeswitch.org] *De la part de* Moises Silva > *Envoyé :* mercredi 2 juin 2010 21:35 > *À :* freeswitch-dev@lists.freeswitch.org > *Objet :* Re: [Freeswitch-dev] FXS bridged on FXO ports and DTMF > > > > I believe the problem was that the driver enabled even outgoing DTMF > detection on the chip ( which does not make much sense by default since you > only care about incoming ) and was fixed a few months ago > > Do you still see this behavior? which driver version? > > Moises Silva > Senior Software Engineer > Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R > 9T3 Canada > t. 1 905 474 1990 x 128 | e. m...@sangoma.com > > On Wed, Jun 2, 2010 at 3:22 PM, <de...@thom.fr.eu.org> wrote: > > I come back on this topic as I did not find a clean/good solution to this > problem. > > > > As reminder, the problem occurs when an FXS channel is bridged on an FXO > channel (seen with sangoma A400 hardware with HW DTMF detection). > > The problem is that each leg of the bridge is detecting the inband DTMF, > and so freeswitch sends each detected DTMF from one leg to the other, and so > on and so forth (as each leg detects the DTMF again and again). > > > > I guess what would be needed for these cases is some application that would > prevent detected DTMF to be sent to the other leg. > > > > Can anybody give me a hint on whether or not such application exists, and > if not, a starting point to try to create one. > > > > Thanks > > > > François > > > > > _______________________________________________ > FreeSWITCH-dev mailing list > 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 > > > > > _______________________________________________ > FreeSWITCH-dev mailing list > 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 > > > > > _______________________________________________ > FreeSWITCH-dev mailing list > 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 > > > > _______________________________________________ > FreeSWITCH-dev mailing list > 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 > >
_______________________________________________ FreeSWITCH-dev mailing list 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
