DTMF conversion / regeneration with bind_digit_action ?
Hi All DTMF troubles again :( We are trying to use Linksys PAP2T / SPA8000 with FS on internal profile and Audiocodes Mediant 2000 as gateway on external. When ATAs set to RFC2833 and proxy media is set on both profiles, everything works fine. We get RFC2833 on both sides. If we turn proxy media off to use freeswitch DTMF features like attended transfer by *7 or another in-call DTMF features, things go worse. PAP2T/SPA8000 convert inband DTMF from phone to RFC2833, but there are some inband clips still coming into audio channel. Freeswitch processes RFC2833 as dtmf-type set to 2833 in internal profile, but since we use bind_digit_action, little inband clip of DTMF gets to other side earlier than regenerated 2833, which is delayed by FS in bind_digit_action / bind_meta_app. BTW, bind_meta_app introduces less delay than bind_digit_action. As the result, after media goes through mediant2000, on PSTN side we have double DTMF - little inband clip and generated RFC2833 with really big gap between them. If some local transfers has been done via internal sip profile, more channels are linked in chain, so delay gets even bigger. When we set DTMF to inband on ATAs and internal profile dtmf-type is set to inband, freeswitch detects inband and in-call features work, but after passing inband DTMF through, FS for some reason also generates RFC2833 on external profile, and then Mediant passes inband part and re-generates rfc2833 DTMF part to PSTN. Again, double DTMF on PSTN side :( Can inband <-> rfc2833 conversion be done on FS side with inband DTMF suppression? And what can be done with in-call DTMF detection functions to make FS pass rfc2833 through as fast as it receives it without delay to make no gap between inband clips and regenerated DTMF? I really appreciate any help. I'm trying to handle this in different ways for two month with no result :( -- Best regards, Dmitry Sytchev, IT Engineer
PAP2T/SPA8000 convert inband DTMF from phone to RFC2833, but there are some inband clips still coming into audio channel.
Which is normal for any device... they generate RFC2833 digits but leave the inband DTMF intact.
Can inband <-> rfc2833 conversion be done on FS side with inband DTMF suppression
No. It detects the tones but doesn't remove them. Freeswitch processes RFC2833 as dtmf-type set to 2833 in internal profile,
but since we use bind_digit_action, little inband clip of DTMF gets to other side earlier than regenerated 2833
FreeSWITCH should only detect inband DTMF if you're calling the start_dtmf app. Are you running that app? If so, don't. It's not needed for out-of-band DTMF such as RFC2833, only for detecting inband DTMF. If you're running it on a channel that's getting both inband and RFC2833 digits you'll get duplicate digits. FS for some reason also generates RFC2833 on external profile
What is the dtmf-type on the external profile? If that's rfc2833 it'll be generating that on the outbound leg even though it's set inband on the receiving profile. -Steve On 22 July 2011 08:24, Dmitry Sytchev <kbdfck@gmail.com> wrote:
Hi All
DTMF troubles again :(
We are trying to use Linksys PAP2T / SPA8000 with FS on internal profile and Audiocodes Mediant 2000 as gateway on external. When ATAs set to RFC2833 and proxy media is set on both profiles, everything works fine. We get RFC2833 on both sides. If we turn proxy media off to use freeswitch DTMF features like attended transfer by *7 or another in-call DTMF features, things go worse.
PAP2T/SPA8000 convert inband DTMF from phone to RFC2833, but there are some inband clips still coming into audio channel. Freeswitch processes RFC2833 as dtmf-type set to 2833 in internal profile, but since we use bind_digit_action, little inband clip of DTMF gets to other side earlier than regenerated 2833, which is delayed by FS in bind_digit_action / bind_meta_app. BTW, bind_meta_app introduces less delay than bind_digit_action.
As the result, after media goes through mediant2000, on PSTN side we have double DTMF - little inband clip and generated RFC2833 with really big gap between them. If some local transfers has been done via internal sip profile, more channels are linked in chain, so delay gets even bigger.
When we set DTMF to inband on ATAs and internal profile dtmf-type is set to inband, freeswitch detects inband and in-call features work, but after passing inband DTMF through, FS for some reason also generates RFC2833 on external profile, and then Mediant passes inband part and re-generates rfc2833 DTMF part to PSTN. Again, double DTMF on PSTN side :(
Can inband <-> rfc2833 conversion be done on FS side with inband DTMF suppression? And what can be done with in-call DTMF detection functions to make FS pass rfc2833 through as fast as it receives it without delay to make no gap between inband clips and regenerated DTMF?
I really appreciate any help. I'm trying to handle this in different ways for two month with no result :(
-- Best regards,
Dmitry Sytchev, IT Engineer
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
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
participants (2)
-
Dmitry Sytchev
-
Steven Ayre