Hi, We have a bugged provider that send us throw RTP wrong DTMF during call. It seems that wrong DTMF are shorter than 1200ms (about 90%) so I want to try to ignore them. For the moment, FS catch them and send it back to the bridged side, boring user. switch_rtp.c:3410 RTP RECV DTMF C:552 Does min-dtmf-duration will make FS ignore them and not RECV them ? I saw the DTMF in "normal" RTP packet, but no digit was pressed in user side. It's commented in my FS switch.conf.xml, how can I see the current value ? <!--<param name="min-dtmf-duration" value="400"/>--> Any other idea ? thanks
Are they sending those digits inband or with RFC2833? -MC On Wed, Dec 5, 2012 at 11:28 AM, Regis M <regis.freeswitch.org@tornad.net>wrote:
Hi,
We have a bugged provider that send us throw RTP wrong DTMF during call. It seems that wrong DTMF are shorter than 1200ms (about 90%) so I want to try to ignore them. For the moment, FS catch them and send it back to the bridged side, boring user.
switch_rtp.c:3410 RTP RECV DTMF C:552
Does min-dtmf-duration will make FS ignore them and not RECV them ? I saw the DTMF in "normal" RTP packet, but no digit was pressed in user side.
It's commented in my FS switch.conf.xml, how can I see the current value ? <!--<param name="min-dtmf-duration" value="400"/>-->
Any other idea ?
thanks _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
Hi, It's RFC2833 DTMF, not inband. Regards, 2012/12/5 Michael Collins <msc@freeswitch.org>
Are they sending those digits inband or with RFC2833? -MC
On Wed, Dec 5, 2012 at 11:28 AM, Regis M <regis.freeswitch.org@tornad.net>wrote:
Hi,
We have a bugged provider that send us throw RTP wrong DTMF during call. It seems that wrong DTMF are shorter than 1200ms (about 90%) so I want to try to ignore them. For the moment, FS catch them and send it back to the bridged side, boring user.
switch_rtp.c:3410 RTP RECV DTMF C:552
Does min-dtmf-duration will make FS ignore them and not RECV them ? I saw the DTMF in "normal" RTP packet, but no digit was pressed in user side.
It's commented in my FS switch.conf.xml, how can I see the current value ? <!--<param name="min-dtmf-duration" value="400"/>-->
Any other idea ?
thanks _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Bummer. I'm not aware of any way to ignore those. Anyone else have ideas? -MC On Thu, Dec 6, 2012 at 12:59 AM, Regis M <regis.freeswitch.org@tornad.net>wrote:
Hi,
It's RFC2833 DTMF, not inband.
Regards,
2012/12/5 Michael Collins <msc@freeswitch.org>
Are they sending those digits inband or with RFC2833? -MC
On Wed, Dec 5, 2012 at 11:28 AM, Regis M <regis.freeswitch.org@tornad.net
wrote:
Hi,
We have a bugged provider that send us throw RTP wrong DTMF during call. It seems that wrong DTMF are shorter than 1200ms (about 90%) so I want to try to ignore them. For the moment, FS catch them and send it back to the bridged side, boring user.
switch_rtp.c:3410 RTP RECV DTMF C:552
Does min-dtmf-duration will make FS ignore them and not RECV them ? I saw the DTMF in "normal" RTP packet, but no digit was pressed in user side.
It's commented in my FS switch.conf.xml, how can I see the current value ? <!--<param name="min-dtmf-duration" value="400"/>-->
Any other idea ?
thanks _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
6 dec 2012 kl. 22:52 skrev Michael Collins <msc@freeswitch.org>:
Bummer. I'm not aware of any way to ignore those. Anyone else have ideas?
The problem with ignoring DTMF in RTP is that it will delay audio, always. Let's say you want to delete all DTMF shorter than 1200 ms. We receive a DTMF begin packet, then will have to wait to 1220 ms to see if the DTMF CONTINUE packets continue or if we actually get a DTMF END packet arriving in time. If it does, we'll delete the DTMF - but that will produce a gap in the audio we will have to fill. If it is longer than 1200 ms we will start playing it out on the other side of the call bridge. You seriously do not want to delay audio 1200 ms. Not even 100 ms. There no simple solution to this. We've had issues with GENBAND servers and their DSPs that send short DTMF in calls with female voices. In short. When we receive the start of the DTMF we have no idea about the duration. We can't make a decision until it's too late to make a decision... If you just focus on delaying DTMF, you will start playing DTMF on top of audio, cancelling out parts of the conversation. /O
-MC
On Thu, Dec 6, 2012 at 12:59 AM, Regis M <regis.freeswitch.org@tornad.net> wrote: Hi,
It's RFC2833 DTMF, not inband.
Regards,
2012/12/5 Michael Collins <msc@freeswitch.org> Are they sending those digits inband or with RFC2833? -MC
On Wed, Dec 5, 2012 at 11:28 AM, Regis M <regis.freeswitch.org@tornad.net> wrote: Hi,
We have a bugged provider that send us throw RTP wrong DTMF during call. It seems that wrong DTMF are shorter than 1200ms (about 90%) so I want to try to ignore them. For the moment, FS catch them and send it back to the bridged side, boring user.
switch_rtp.c:3410 RTP RECV DTMF C:552
Does min-dtmf-duration will make FS ignore them and not RECV them ? I saw the DTMF in "normal" RTP packet, but no digit was pressed in user side.
It's commented in my FS switch.conf.xml, how can I see the current value ? <!--<param name="min-dtmf-duration" value="400"/>-->
Any other idea ?
thanks _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks. But does FS start replaying it on other leg at the end or while it receive info. I had begin to reduce impact by binding digit action, but It seems the problem is still here. I know if i need dtmf or not in some calls, so, any other way to ignore ALL dtmf ? :) Regards 2012/12/7 Olle E. Johansson <oej@edvina.net>
6 dec 2012 kl. 22:52 skrev Michael Collins <msc@freeswitch.org>:
Bummer. I'm not aware of any way to ignore those. Anyone else have ideas?
The problem with ignoring DTMF in RTP is that it will delay audio, always. Let's say you want to delete all DTMF shorter than 1200 ms. We receive a DTMF begin packet, then will have to wait to 1220 ms to see if the DTMF CONTINUE packets continue or if we actually get a DTMF END packet arriving in time. If it does, we'll delete the DTMF - but that will produce a gap in the audio we will have to fill. If it is longer than 1200 ms we will start playing it out on the other side of the call bridge.
You seriously do not want to delay audio 1200 ms. Not even 100 ms.
There no simple solution to this. We've had issues with GENBAND servers and their DSPs that send short DTMF in calls with female voices.
In short. When we receive the start of the DTMF we have no idea about the duration. We can't make a decision until it's too late to make a decision... If you just focus on delaying DTMF, you will start playing DTMF on top of audio, cancelling out parts of the conversation.
/O
-MC
On Thu, Dec 6, 2012 at 12:59 AM, Regis M <regis.freeswitch.org@tornad.net>wrote:
Hi,
It's RFC2833 DTMF, not inband.
Regards,
2012/12/5 Michael Collins <msc@freeswitch.org>
Are they sending those digits inband or with RFC2833? -MC
On Wed, Dec 5, 2012 at 11:28 AM, Regis M < regis.freeswitch.org@tornad.net> wrote:
Hi,
We have a bugged provider that send us throw RTP wrong DTMF during call. It seems that wrong DTMF are shorter than 1200ms (about 90%) so I want to try to ignore them. For the moment, FS catch them and send it back to the bridged side, boring user.
switch_rtp.c:3410 RTP RECV DTMF C:552
Does min-dtmf-duration will make FS ignore them and not RECV them ? I saw the DTMF in "normal" RTP packet, but no digit was pressed in user side.
It's commented in my FS switch.conf.xml, how can I see the current value ? <!--<param name="min-dtmf-duration" value="400"/>-->
Any other idea ?
thanks
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
For the reasons RFC2833 Olle already mentioned, on a bridge FS *must* forward the RFC2833 onto the other leg before it has received the end packet. If FS waited for the end packet before deciding to forward the RTP then you'd get a 1200ms+ lag on audio. On 7 December 2012 12:59, Regis M <regis.freeswitch.org@tornad.net> wrote:
Thanks. But does FS start replaying it on other leg at the end or while it receive info. I had begin to reduce impact by binding digit action, but It seems the problem is still here.
I know if i need dtmf or not in some calls, so, any other way to ignore ALL dtmf ? :) Regards
2012/12/7 Olle E. Johansson <oej@edvina.net>
6 dec 2012 kl. 22:52 skrev Michael Collins <msc@freeswitch.org>:
Bummer. I'm not aware of any way to ignore those. Anyone else have ideas?
The problem with ignoring DTMF in RTP is that it will delay audio, always. Let's say you want to delete all DTMF shorter than 1200 ms. We receive a DTMF begin packet, then will have to wait to 1220 ms to see if the DTMF CONTINUE packets continue or if we actually get a DTMF END packet arriving in time. If it does, we'll delete the DTMF - but that will produce a gap in the audio we will have to fill. If it is longer than 1200 ms we will start playing it out on the other side of the call bridge.
You seriously do not want to delay audio 1200 ms. Not even 100 ms.
There no simple solution to this. We've had issues with GENBAND servers and their DSPs that send short DTMF in calls with female voices.
In short. When we receive the start of the DTMF we have no idea about the duration. We can't make a decision until it's too late to make a decision... If you just focus on delaying DTMF, you will start playing DTMF on top of audio, cancelling out parts of the conversation.
/O
-MC
On Thu, Dec 6, 2012 at 12:59 AM, Regis M <regis.freeswitch.org@tornad.net
wrote:
Hi,
It's RFC2833 DTMF, not inband.
Regards,
2012/12/5 Michael Collins <msc@freeswitch.org>
Are they sending those digits inband or with RFC2833? -MC
On Wed, Dec 5, 2012 at 11:28 AM, Regis M < regis.freeswitch.org@tornad.net> wrote:
Hi,
We have a bugged provider that send us throw RTP wrong DTMF during call. It seems that wrong DTMF are shorter than 1200ms (about 90%) so I want to try to ignore them. For the moment, FS catch them and send it back to the bridged side, boring user.
switch_rtp.c:3410 RTP RECV DTMF C:552
Does min-dtmf-duration will make FS ignore them and not RECV them ? I saw the DTMF in "normal" RTP packet, but no digit was pressed in user side.
It's commented in my FS switch.conf.xml, how can I see the current value ? <!--<param name="min-dtmf-duration" value="400"/>-->
Any other idea ?
thanks
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, Dec 6, 2012 at 11:08 PM, Olle E. Johansson <oej@edvina.net> wrote:
6 dec 2012 kl. 22:52 skrev Michael Collins <msc@freeswitch.org>:
Bummer. I'm not aware of any way to ignore those. Anyone else have ideas?
The problem with ignoring DTMF in RTP is that it will delay audio, always. Let's say you want to delete all DTMF shorter than 1200 ms. We receive a DTMF begin packet, then will have to wait to 1220 ms to see if the DTMF CONTINUE packets continue or if we actually get a DTMF END packet arriving in time. If it does, we'll delete the DTMF - but that will produce a gap in the audio we will have to fill. If it is longer than 1200 ms we will start playing it out on the other side of the call bridge.
You seriously do not want to delay audio 1200 ms. Not even 100 ms.
There no simple solution to this. We've had issues with GENBAND servers and their DSPs that send short DTMF in calls with female voices.
In short. When we receive the start of the DTMF we have no idea about the duration. We can't make a decision until it's too late to make a decision... If you just focus on delaying DTMF, you will start playing DTMF on top of audio, cancelling out parts of the conversation.
/O
OEJ, +1 Many thanks for taking the time to explain that! That was an extremely well written paragraph, easily understood by all. -MC
participants (4)
-
Michael Collins
-
Olle E. Johansson
-
Regis M
-
Steven Ayre