[Freeswitch-dev] FXS bridged on FXO ports and DTMF

Mon Jun 7 16:29:24 PDT 2010

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. moy at sangoma.com

On Mon, Jun 7, 2010 at 4:17 PM, <devel at 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-bounces at lists.freeswitch.org [mailto:
> freeswitch-dev-bounces at lists.freeswitch.org] *De la part de* Moises Silva
> *Envoyé :* jeudi 3 juin 2010 23:35
>
> *À :* freeswitch-dev at 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. moy at sangoma.com
>
>  On Thu, Jun 3, 2010 at 6:46 AM, François Legal <devel at 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.silva at 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. moy at sangoma.com
>
>  On Wed, Jun 2, 2010 at 4:19 PM, <devel at thom.fr.eu.org> wrote:
>
> I just updated to 3.5.11 and the result is the same.
>
>
>
> *De :* freeswitch-dev-bounces at lists.freeswitch.org [mailto:
> freeswitch-dev-bounces at lists.freeswitch.org] *De la part de* Moises Silva
> *Envoyé :* mercredi 2 juin 2010 21:35
> *À :* freeswitch-dev at 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. moy at sangoma.com
>
> On Wed, Jun 2, 2010 at 3:22 PM, <devel at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100607/7693fef6/attachment-0001.html 