[Freeswitch-users] DTMF Passthrough on different legs

[Steven Ayre]

Re codec prefs... There is no such thing as 'G711' and it'll be ignored. It would be best to remove that from your config for clarity and to avoid problems later, eg you think you have 711 enabled but you don't because you have G711 but have removed PCMx. PCMA and PCMU are the correct definitions for G711.

-Steve

Sent from my iPad



On 31 May 2012, at 20:24, Michael Lutz <mytemike72 at gmail.com> wrote:

> According to CDRS's:
> 
> Session:A -> Inbound, PCMU-8000
> Session B -> FS to FS, PCMU-8000
> Session C -> Outbound, PMCA-8000
> 
> According to vars.xml:
>    <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G711,PCMU,PCMA"/>
>    <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=G711,PCMU,PCMA"/>
> 
> 
> Regards,
> Mike.
> 
> 2012/5/31 JRichey <jrichey at itltd.net>:
>> 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
>> 
>> 
>> 
>> _________________________________________________________________________
>> 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
> 
> _________________________________________________________________________
> 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