[Freeswitch-users] DTMF conversion / regeneration with bind_digit_action ?

[Steven Ayre]

>
> 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 at 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 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/20110722/e29ca86a/attachment.html