[Freeswitch-users] DTMF Passthrough on different legs

[JRichey]

What CODECs are being used?

In-band DTMF won't work correctly with compressed CODECs like G.729.


-----Original Message-----
From: freeswitch-users-bounces at lists.freeswitch.org
[mailto:freeswitch-users-bounces at lists.freeswitch.org]On Behalf Of
Michael Lutz
Sent: Thursday, May 31, 2012 2:12 AM
To: FreeSWITCH Users Help
Subject: [Freeswitch-users] DTMF Passthrough on different legs


Hi Guys,

I am stuck with a bit of a problem I cannot figure out where it is going
wrong..

Here's my situation,

I have an inbound call, comming from an external provider, they don't
support RFC2833 so I turn on inband detection using 'start_dtmf' in
the dialplan.
This works ok, for the incomming channel and IVR provided (via Lua) to
the caller. (Though sometimes it seems to misinterpret and returns
wrong keys..) (Session:A)

After that, this call is bridged (via Lua to a a new inbound session
on the same switch) (without specifying start_dtmf) so RC2388 is used
by default (?) (Session:B)

This new sessions is playing soem audio (Lua) and is heard by the
original caller (the two sessions are bridged).


Seperatly I have an inbound ESL connection where I do an origanate
using a originate {execute_on_answer=start_dtmf, .... etc) &park() to
setup an new external call via the same gateway (they don't support
RFC2388 so I activate the inband detection on the b-leg to receive the
digits.
Let's call this leg Session:C.

After the orignated call is answered I bridge the parked call with the
previous session (Session:B), so at the end Session:A and Session:B
can talk to each other.

Al this works perfectly.

[Incommming call] Session:A ----- INBAND ------> Bridge(FS.Lua) --->
Session:B ---- RFC2388 ---->   FS.Bridge ---> Session:C --- INBAND
------> ESL destination number


My symptoms are...

1. I have a customer who had a IVR on his own side, (Session:C) and
requires input from Session:A. The weird thing is that it seems the
input is wrong.
Keys entered do not correspond to what his IVR is receiving. As if
newly dtmfs are generated somewhere.
When I switch to another inbound provider, making Session:A using
rfc2388 and not inband, but do dialout via the provider using inband
detection. It seems to work fine.


2. Not being able to get the dtmf's from the ESL Destination number
(Session:C). I'm reading this by subscribing to events via ESL for
that particulair uuid.
When I have a connection (inbound) without inband detection it seems
to get the DTMF's from Session:C without any problems. Which makes it
weird for me.

note: I know the setup is a bit odd, but Session A cannot exit it's
Lua script, so I needed to do a workaround to be able to keep te lua
alive and being able to control the call (audio) via ESL.

I realy need some help on this one, becuase we have a lot of customers
complaining about not responding to dtmf's or receving invalid input
in the (FS) IVR.


Thanks for you help,

Regards,
Mike.

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting at freeswitch.org
http://www.freeswitchsolutions.com




Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

Join Us At ClueCon - Aug 7-9, 2012

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