[Freeswitch-users] Double-dtmf detection in IVR when a call is routed through FreeSWITCH

Drew Ozier drew.ozier at gmail.com
Wed May 27 08:25:53 PDT 2009


Hey Brian,

It is a bridged call. Here's the majority of my dialplan:
<condition field="source" expression="mod_sofia">
        <action application="ring_ready"/>
        <action application="pre_answer"/>
        <action application="start_dtmf"/>
        <action application="set"
data="effective_caller_id_number=${caller_id_number}"/>
        <action application="set" data="RECORD_STEREO=true"/>
        <action application="set" data="aleg_uuid=${uuid}"/>
        <action application="set"
data="call_id=${strftime(%Y-%m-%d-%H-%M-%S)}_${destination_number}_${uuid}"/>
        <action application="set"
data="outfile=$${base_dir}/recordings/${call_id}.wav"/>
        <action application="record_session" data="${outfile}"/>
        <action application="set" data="progress_timeout=20"/>
        <action application="set" data="call_timeout=90"/>
        <action application="set"
data="bridge_pre_execute_bleg_app=start_dtmf"/>
        <action application="set"
data="continue_on_fail=NORMAL_TEMPORARY_FAILURE"/>
        <action application="set" data="hangup_after_bridge=true"/>
        <action application="bridge" data="sofia/normal_customer/${
outdial}@10.1.10.10 <outdial%7D at 10.1.10.10>"/>
        <action application="bridge" data="sofia/normal_customer/${
outdial}@10.1.10.10 <outdial%7D at 10.1.10.10>"/>
</condition>

On Wed, May 27, 2009 at 11:12 AM, Brian West <brian at freeswitch.org> wrote:

> You should try to always use out of band... what is the call path because
> it looks like a bridged call and the far end gets the inband and the 2833
> /b
>
> On May 27, 2009, at 10:02 AM, Drew Ozier wrote:
>
> To clarify, I'm not running the IVR. I have a TDM T1 that comes in to an
> AudioCodes Mediant 1000 (SIP Gateway) which goes to a FreeSWITCH machine. I
> receive calls coming in off the T1 which goes through my Mediant 1000 which
> goes to my FreeSWITCH machine which makes an outbound call back through the
> Mediant 1000 to an IVR (bridging the inbound and outbound calls). I have
> (supposedly) configured the AudioCodes Mediant 1000 to pass the DTMF
> in-band, because I want to minimize the amount of modifications I make to
> the audio stream going through my system. I also want to be able to log when
> DTMF events occur for analysis purposes. If I do not have start_dtmf, then
> FreeSWITCH does not show me any DTMF in the logs, but when I have it on, it
> will.
>
> Here's a DTMF event in my FreeSWITCH logs:
> (I changed the debug message to a notice and added the callId and the nano
> time of the event)
> 2009-05-26 16:02:05 [NOTICE] switch_ivr_async.c:996 inband_dtmf_callback()
> 348323 61182225861200042042 at 10.1.10.10 DTMF DETECTED: 5
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1322 do_2833() Send start packet
> for [5] ts=1217893935 dur=160/160/2000 seq=55199
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=320/320/2000 seq=55200
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=480/480/2000 seq=55201
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=640/640/2000 seq=55202
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=800/800/2000 seq=55203
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=960/960/2000 seq=55204
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=1120/1120/2000 seq=55205
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=1280/1280/2000 seq=55206
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=1440/1440/2000 seq=55207
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=1600/1600/2000 seq=55208
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=1760/1760/2000 seq=55209
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send middle packet
> for [5] ts=1217893935 dur=1920/1920/2000 seq=55210
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send end packet for
> [5] ts=1217893935 dur=2080/2080/2000 seq=55211
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send end packet for
> [5] ts=1217893935 dur=2080/2080/2000 seq=55212
> 2009-05-26 16:02:05 [DEBUG] switch_rtp.c:1258 do_2833() Send end packet for
> [5] ts=1217893935 dur=2080/2080/2000 seq=55213
>
> Does the fact that switch_rtp is sending packets mean that FreeSWITCH is
> sending out-of-band DTMF as well as recognizing the in-band?
>
> Thanks for your quick replies, hopefully this will make my issue clearer.
>
> -Drew
>
>
> Brian West
> brian at freeswitch.org
>
> -- Meet us at ClueCon!  http://www.cluecon.com
>
>
>
>
>
> _______________________________________________
> 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/20090527/18137f95/attachment-0002.html 


More information about the FreeSWITCH-users mailing list