<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I have searched the archives (and indeed the Internet at large) and
everything I found pointed me to the perfect solution to all my
problems: get ROIC (Reverse On Idle Condition) enabled on my phone
line.<br>
<br>
Sadly further investigation revealed that Telstra (who provides most
PSTN services in Australia, including mine) has decided to
discontinue offering ROIC as of 2008:<br>
<blockquote type="cite">Line reversals were withdrawn from new sales
June/July this year [2008] and will be removed from existing
services June/July next year [2009].<br>
</blockquote>
(<a class="moz-txt-link-freetext" href="http://forums.whirlpool.net.au/archive/1076769">http://forums.whirlpool.net.au/archive/1076769</a>).<br>
<br>
Let me describe the kinds of problem I am observing:<br>
<ol>
<li>Remote party calls, waits for 5 seconds, then hangs up before
I have answered. My phones go on ringing for another 25 seconds
until voicemail kicks in and answers the call at the 30 second
mark. I get a voicemail message containing nothing but a dial
tone (there is a problem with using tone_detect to avoid this,
but that is a topic for another post).</li>
<li>First remote party calls, waits for 15 seconds, then hangs up.
Second remote party calls 10 seconds later. 5 seconds after the
second call starts, voicemail kicks in and answers, believing
that there has only been one caller and that the phone has been
ringing for 30 seconds.</li>
</ol>
<p>Now I accept that to some extent these kinds of problems are
unavoidable without the assistance of something like ROIC. There
is no immediate way to tell the difference between a gap between
two RINGs and the remote caller having hung up. The difference
only becomes obvious at the time when the next RING ought to have
started (I suppose a RING that was cut short could also be
detected, but since the gaps are longer than the RINGs it is more
likely that the hangup will occur during a gap).<br>
</p>
<p>Likewise, if a second caller comes along just perfectly starting
at the instant that the next RING was due for the first caller
then I can't see how FreeTDM can avoid being tricked.<br>
</p>
<p>However, at present, FreeTDM totally ignores FTDM_OOB_RING_STOP
events, and only seems to take notice of the first
FTDM_OOB_RING_START event (well it counts rings, but doesn't seem
to notice that the count has stopped increasing, at least not
until more than 25 seconds after the ringing has stopped). This
creates an unnecessarily long window of opportunity for problems.<br>
</p>
<p>Given the Australian ring cadence (0.4s RING, 0.2s gap, 0.4s
RING, 2s gap) it is possible to detect the caller having hung up
within at most 2 seconds - simply reset a timer on each
FTDM_OOB_RING_START and FTDM_OOB_RING_STOP event, and reset the
line state if the timer gets over 2 seconds. I have implemented
this (rather awkwardly), and it works well for me, but my timeout
is hard-coded and therefore it would not work with a US cadence
(2s RING, 4s gap).<br>
</p>
What I would ideally like to see is for FreeTDM to support RING
cadence specification (both for detection on the FXO lines and for
distinctive ring on the FXS lines) but that would be a big job and
way out of my league.<br>
<br>
Failing that, there would need to be some config setting to control
how long to wait for a RING_START/RING_STOP event before concluding
the caller had hung up. Which config file would be the most logical
place? freetdm.conf just in case different channels need different
timeouts?<br>
<br>
Or is there some better approach to the whole problem?<br>
<br>
[I am a little surprised there has not been more complaint about
these issues. If nobody else suffers from the same problems then
perhaps I just have something misconfigured??]<br>
<br>
</body>
</html>