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

[Dmitry Sytchev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110722/03417d8f/attachment.html