[Freeswitch-users] openzap and progress detection

Francois Delawarde fdelawarde at wirelessmundi.com
Mon May 18 01:29:30 PDT 2009


I'm in Spain with an analog TDM400 Clone from OpenVox (with 1xFXO
+1xFXS), and am trying first to make the FXO work with Openzap and
Freeswitch (using dahdi 2.2.0-rc4). Openzap perfectly detects and loads
the spans, but I'm currently enable to dial out with the FXO module, it
doesn't dial anything and times-out after 30 seconds.  I believe it has
to do with some tone detection and  therefore have a few questions:

- When I plug in the line, dahdi sends an event (event 17) that is
ignored by OZ. Can we enable some type of battery check in OZ before
dialing out, or is there some variable to monitor battery (oz dump
doesn't show the battery status)?

- Does OZ use the polarity switch events sent by dahdi (in kewlstart
mode) for answer and hangup detection?

- Apparently, OZ does tone progress detection by frequency, but here in
Spain, most tones use the same 425Hz frequency with different on-off
timing. Is it possible to detect those?

- As some PBX in Spain transfer calls by first hanging up and picking up
on another phone, can we enable/disable parts of polarity switch and/or
tone progress detection (ex: (hangup)/(answer)onpolarityswitch in

- Some lines here are connected to very old FXS from operators that have
low sound quality and can take a few seconds to give a dial tone when
picking up. Is it possible to introduce a delay before sending DTMF
digits when dialing? Is it possible to "relax" DTMF detection, and tweak
DTMF settings (make them a bit longer, with a longer pause for the other
side to detect)?

My "ideal" case to make it work in every case around here would be to:
- have OZ fail to dial if battery is not present (and be able to fetch
battery status somehow)
- disable tone progress (sometimes call ends up on some local PBX that
answers and provides US tones which are different)
- be able to have an initial pause before dialing with DTMF digits
- use polarity switch to detect remote answer, but not hangup (for
transfer issues)

Is the above possible?

Thanks in advance,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090518/23cd173e/attachment-0002.html 

More information about the FreeSWITCH-users mailing list