[Freeswitch-users] Remove inband DTMF on record_session
cstomi.levlist at gmail.com
Tue Jan 29 11:36:26 MSK 2013
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
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
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
or advise a working one?
Thanks in advance,
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?
> 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).
>> On 25 January 2013 14:27, Matt Broad <matt at inveroak.com> wrote:
>> 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?
>> 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 :)
>> 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:
>> Is there a way to to remove inbad DTMF from the recorded wav file
>> 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
>> 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
> 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
> Official FreeSWITCH Sites
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users