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. On Tue, Sep 2, 2008 at 12:48 PM, Luis F Urrea <lfurrea@gmail.com> wrote:

Hi Anthony,

Thanks for your response. I find strange that this is not a common feature, it's really difficult to get Telcos to answer to magic words such as disconnect supervision.

If tone based disconnect is not used, is "current interrupt" the only supported disconnect method on a loopstart line or is it polarity reversal supported as well?

Regards,

On Tue, Sep 2, 2008 at 9:43 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:

...

openzap does not have tone based hangup detection support coded into it. That's why it only works when you use FreeSWITCH to do it in the general dialplan.

It's simply a feature we have not had demand for yet in OpenZAP. I'm sure we could add it if we can find the time/resources.

On Mon, Sep 1, 2008 at 7:47 PM, Luis F Urrea <lfurrea@gmail.com> wrote:

...

Hi All,

I have been working for quite a while in trying to get Openzap to recognize my country specific busy tone in order to hang up an analog FXO channel.

Basically, I am having FXO disconnect supervision issues and I wanted to know if it's possible to hang up the FXO by monitoring call progress tones so that when there is a busy tone the FXO goes on hook.

I have been tweaking the /etc/openzap/tones.conf based on the ITU.T recommendation E.180 for my country, but so far it doesn't even seem that the changes I make to the tones.conf file are considered when dealing with disconnects from the PSTN side.

I restart FS after every change I make to /etc/openzap/tones.conf with no positive results.

The Openzap Wiki states that the "loadzone" parameter in /etc/zaptel.conf is not considered when dealing with tones, which makes sense since Openzap seems to use libteletone for tone detection and generation.

Here is what I use for busy tone on /etc/openzap/tones.conf:

[us]

generate-busy => v=-7;%(330,330,450) detect-busy => 450

Therefore I set openzap.conf.xml as follows:

<param name="tonegroup" value="us"/>

I was able to check that the busy tone can be detected using the following dial plan rule:

1. <extension name="Inbound"> 2. <condition field="destination_number" expression="^1$"> 3. <action application="answer"/> 4. <action application"sleep" data="1000"/> 5. <action application="tone_detect" data="busy 450,0 r +100 hangup normal_clearing"/> 6. </condition> 7. </extension>

So that I answer the FXO and hang up when the busy tone is detected. It works fine and the FXO port does not get stuck.

Here's the output from the log for the rule above:

http://pastebin.com/f43500bd3

I do not see a reason why settings on tones.conf may not be working?

Is disconnect on busy-detect the default for Openzap? Is it power denial or battery reversal?

Does it matter if I select fxsks in /etc/zaptel.conf instead of fxsls?

Your help will be greatly appreciated.

Regards,

Luis

_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

_______________________________________________ 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

_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

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.

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

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 _______________________________________________ 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 <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400

I didn't say I needed to be convinced to add it. I said I needed the time and resources to work on it. Everyone else on your list of who supports this feature is a commercial product. We don't actually get much out of the deal being FREE switch and all. It's certainly on the list of features we intend to add I just don't know when it will be added. Again you can configure FreeSWITCH to do the same thing with the tone_detect app as you have already demonstrated so it's not exactly a high priority issue at the moment. I'm sure you will see it added at some point. On Tue, Sep 2, 2008 at 5: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

_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400