Here’s a snippet of what I use with tone_detect, although I don’t actually look for a ring signal:

 

  <extension name="ivr_start">

    <condition field="destination_number" expression="^82(\d{10})$">

      <!-- we can skip all this early media stuff if the far end answers -->

      <action application="set" data="execute_on_answer=transfer IVRANSWERCALL XML default"/>

      <action application="sleep" data="100"/>

      <action application="pre_answer"/>

      <!--<action application="record_session" data="/mnt/powervault/Databases/XMLCDR/${uuid}__1.wav"/>-->

      <action application="sleep" data="500"/>

      <!-- If call gets here then probably we're in progress media; get ready to handle various tones -->

      <!-- Look for busy and SIT tones right away, then wait a bit before looking for a ring signal -->

      <action application="tone_detect" data="BUSY 480,620 r +25000 set BUSY=true"/>  <!-- detect busy -->

      <action application="tone_detect" data="SIT1LO 913.8 r +25000 set SIT1LO=true"/>   <!--1st segment low -->

      <action application="tone_detect" data="SIT1HI 985.2 r +25000 set SIT1HI=true"/>   <!--1st segment high -->

      <action application="tone_detect" data="SIT2LO 1370.6 r +25000 set SIT2LO=true"/>   <!--2nd segment low -->

      <action application="tone_detect" data="SIT2HI 1428.5 r +25000 set SIT2HI=true"/>   <!--2nd segment high -->

      <action application="tone_detect" data="SIT3LO 1776.7 r +25000 set SIT3LO=true"/>  <!--3rd segment low -->

      <action application="tone_detect" data="SITITU1 950 r +25000 set SITITU1=true"/>   <!--2nd segment low -->

      <action application="tone_detect" data="SITITU2 1400 r +25000 set SITITU2=true"/>   <!--2nd segment high -->

      <action application="tone_detect" data="SITITU3 1800 r +25000 set SITITU3=true"/>  <!--3rd segment low -->

      <action application="set" data="ivr_result=unknown"/>

      <action application="sleep" data="25010"/>

      <action application="lua" data="check_sit.lua"/> <!-- Check for SIT or BUSY flags -->

      <!-- if we make it all the way here then it's a pretty good chance that it is a real no answer -->

      <action application="transfer" data="IVRNOANS XML default"/>

    </condition>

  </extension>

 

If you added something like this:

<action application="tone_detect" data="RING 440,480 r +25000 set RING=true"/>  <!-- detect ring -->

 

Then you’d be able to detect ringing, assuming these frequencies match your country’s ring frequencies.

-MC

 

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale
Sent: Tuesday, September 02, 2008 3:35 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Openzap: Analog FXO disconnect supervision.Is it possible to disconnect on busy? is battery reversal thedefault? is it power denial?

 

you just put the tone_detect app right before the bridge app
you might have to also execute pre_answer to get an early media stream up into FS

On Tue, Sep 2, 2008 at 5:23 PM, Luis F Urrea <lfurrea@gmail.com> wrote:

Anthony,

So far I haven't been able to used the tone_detect app with hangup when it involves a phone ringing, Could you provide an example of a dialplan rule that I could test.

TIA

 

On Tue, Sep 2, 2008 at 4:18 PM, Luis F Urrea <lfurrea@gmail.com> wrote:

I understand that tone based disconnect could be subject to false disconnects in some cases, being dependent  on the integrity of the analog signal and the proper configuration of tones, however I do feel that the feature is worth the effort, considering how difficult it is to get a Telco to arrange changes of settings on analog lines and being a last resort for this kind of situation.

I do know however that this feature is implemented for example on Cisco IOS for analog gateways, Audiocodes gateways and Patton gateways.

Cisco IOS and Patton requires one to specify the frequencies and cadence of the tone, Audiocodes provides an application that records the call progress tones and then analyzes the recorded busy signal to be used as the disconnect signal.

I used to work at Cisco TAC supporting H323 analog and digital gateways, and in my experience the feature certainly saved the day in many cases after the customer was frustrated in trying to find out what his/her provider implemented on the line.

My vote goes for it!



On Tue, Sep 2, 2008 at 1:05 PM, Michael Jerris <mike@jerris.com> wrote:

We do have the following patch almost ready to merge:

http://jira.freeswitch.org/browse/OPENZAP-3

it could probably be expanded to work for other tones than dtmf, with
the caveats described by tony.

Mike


On Sep 2, 2008, at 2:22 PM, Anthony Minessale wrote:

> Any method besides the tone based ones are supported by whichever IO
> layer you choose.
> For instance if you are using the zt mod (zaptel) then all the low
> level analog signalling will be generated by zaptel for ground loop
> and kewl start etc.
>
> Tone based hangup detection is a higher level concept that could be
> implemented in the core of openzap but would require constant tone
> detection throughout the call and is susceptible to false positives
> etc.
>
> it's not a common feature where I wrote the code from.  I have
> kewlstart lines here and nobody has asked for it and I don't have a
> labbed up example and I only have 2 hands therefore it's not
> implemented.
>
> Like I said using tone_detect in FreeSWITCH with action hangup is
> not any more or less glorious than how the feature would work right
> in openzap so you can use it that way if you want.
>

 

 


_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org




--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:213-799-1400