[Freeswitch-users] Remove inband DTMF on record_session

[Tamas Cseke]

Hello,

Anthony, could I ask your opinion, suggestions about removing inband dtmf
from recorded files?
We checked how we could add this feature to record_session, but I have some
questions

teletone dtmf detector needs more farme to detect dtmf, so I think we can't
use media bug to replace the frames
So we are thinking about to add a buffering and a dtmf detector
if dtmf has been detected, the farmes in the buffer should be overwritten
with silence

It could goes to:
1) record_session app
2) file api (here buffering is implemented, but adding a detector to every
file handle seems to be pretty ugly solution)
3) a new file format, that makes another level buffering

Could you please let me know, if any of them could work? (I don't really
like them)
or advise a working one?

Thanks in advance,
Tamas


On Fri, Jan 25, 2013 at 9:14 PM, Matt Broad <matt at inveroak.com> wrote:

> Thanks for the response Steve, is there a way of checking the dtmf type? I
> have tried looking at the Sofia profile but cannot see any details
> regarding dtmf.
>
>  I assume that this is determined by my sip provider?
>
>
> Thanks
> Matt
>
>
> On Friday, 25 January 2013, Steven Ayre wrote:
>
>> If you're using RFC2833 then that's not in the audio itself so won't be
>> recorded. It is possible though that the caller is ending DTMF both in and
>> out of band (which is fine as long as you only try to detect one or the
>> other but not both).
>>
>> -Steve
>>
>>
>>
>> On 25 January 2013 14:27, Matt Broad <matt at inveroak.com> wrote:
>>
>> Hi,
>>
>> sorry to interject into your message, but I was looking to do something
>> similar to Tamas.
>>
>> I have the need to prevent the DTMF from being recorded when using
>> record_session. I am using RFC2833 (i think :) ), is this at all possible
>> in the current Freeswitch build?
>>
>> Matt
>>
>>
>> On 21 January 2013 07:25, Tamas Jalsovszky <jalsot at gmail.com> wrote:
>>
>> Hello Moy,
>>
>> Inserting silence instead of the tone would be fine for me. I think the
>> >= 50ms delay in recording is not an issue. I guess, removing from "live"
>> streams would be harder and would introduce the delay you mentioned.
>> So you have a plan to add such a functionality in the near future? That
>> would be amazing :)
>>
>> Regards,
>>   Jalsot
>>
>> On Mon, Jan 21, 2013 at 2:48 AM, Moises Silva <moises.silva at gmail.com>wrote:
>>
>> On Sun, Jan 20, 2013 at 4:12 PM, Tamas Jalsovszky <jalsot at gmail.com>wrote:
>>
>> Hello,
>>
>> Is there a way to to remove inbad DTMF from the recorded wav file
>> (conditionaly)?
>> If not, how could be that done the easyiest way and a way it could get
>> into FS git?
>>
>> As FS has a great DTMF detector and it has probably all the stuff doing
>> such a feature, I think it would be much better than using an external tool
>> for removing DTMF from finished wav file - and it would consume more I/O
>> probably.
>>
>>
>> Removing it would not be that hard (ie, inserting silence instead).
>> Removing it without leaving a trace any DTMF was ever there sounds a tad
>> more difficult. If you're ok with inserting a silence instead of the tone,
>> extending the record_session app to detect and remove DTMF is probably what
>> I'd do.
>>
>> It is also possible to create a new app that monitors the audio stream
>> and silence the stream when DTMF is detected, but since the detection takes
>> a few milliseconds (~50ms), there would be a bit of "bleeding" of DTMF in
>> the signal, unless the new app also delays the signal by 50ms and then has
>> a way to strip the DTMF completely.
>>
>> *Moises Silva
>> **Manager, Software Engineering***
>>
>> msilva at sangoma.com
>>
>> Sangoma Technologies
>>
>> 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada
>>
>>
>
> --
> Thanks
> Matt
>
> This email and any attachments to it are confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of InverOak Limited.
>
> If you are not the intended recipient of this email, you must neither take
> any action based upon its contents, nor copy or show it to anyone. Please
> contact the sender if you believe you have received this email in error.
>
> This email including any attachments cannot be guaranteed to be 100%
> secure or error-free as information could be intercepted, corrupted, lost,
> destroyed, out-dated, or containing viruses. The sender therefore does not
> accept liability for any errors or omissions in the contents of this
> message which arise as a result of email transmission.
>
> InverOak Limited is a company registered in England & Wales under company
> number 04529594, whose registered address is Old Barn house, 2 Wannions
> Close, Botley, Chesham, Buckinghamshire, HP5 1YA, United Kingdom.
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130129/998a53f7/attachment.html