Hi Vasilis,<br><br>Good points .. my comments inline.<br><br>Regards,<br><br>Ahmed.<br><br><div class="gmail_quote">2010/1/8 Vlasis Hatzistavrou (KTI) <span dir="ltr"><<a href="mailto:vhatz@kinetix.gr">vhatz@kinetix.gr</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello Ahmed,<br>
<div class="im"><br>
On 8/1/10 6:07 μμ, Ahmed Naji wrote:<br>
> My line of thought is to tone-detect secondary ringing tones post<br>
> 200(OK) to detect FAS (False Answer Supervision). This should<br>
> eliminate at least a good proportion of calls, and it can be done real<br>
> time through a script/modules/...etc.<br>
><br>
<br>
</div>Tone detection can work only in cases where actual tones are sent over<br>
the audio. There are some routes (especially mobile routes) where<br>
different ringtones or music can be used instead of ringback tones,<br>
which render the whole tone detection effort difficult. There are also<br>
cases where no audio at all is sent until the called party answers the<br>
phone. Not to mention that the "FASed" route's behavior can change over<br>
time, rendering an effort for permanent FAS detection futile.<br>
<div class="im"><br></div></blockquote><div>True. One way of dealing with coloured ringing tones is quiet straight forward with acoustics libraries for C++ and such like. No audio is also possible to deal with in this fashion.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> Working along this thought, at least you are minimising the hit<br>
> cost-wise to a few seconds at most.<br>
<br>
</div>Well, even if you manage to detect FAS given to you by your termination<br>
provider, you cannot really minimize loss, as typically calls are<br>
charged by the time difference between 200(OK) and BYE.</blockquote><div>True, but the idea is to minimise this duration, and hangup the call ASAP.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You can't really<br>
dispute anything even if you manage to detect FAS in real time, because<br>
you cannot prove this in a court or to anyone else by presenting CDRs<br>
only. You can't really pinpoint in a list of calls which ones had FAS.<br>
And of course, the terminating partner who gives FAS will deny it most<br>
of the times.<br></blockquote><div>Absolutely right on all accounts. At least in doing so, you are minimising the financial hit, particularly on busy routes that carry a high premium.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
><br>
> As to answering machines and fake conferences, fake network messages<br>
> ...etc, one can possibly use voice detection, perhaps with heuristic<br>
> and statistical training.<br>
<br>
</div>You will need to combine tones detection, music detection, answering<br>
machine detection, which in the end makes the whole effort pointless.<br></blockquote><div>Debatable. Hard, yes, but pointless ? I don't really agree.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You will need to use DSP in software or in hardware to even try<br>
accomplish this (which means additional cost),</blockquote><div>DSP techniques - to some extent, if you really want to go that far. The idea is to do it all in FS, and not really employ expensive software/hardware techniques as you so rightly state.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> and for what? For trying<br>
to detect FAS on a route which is not suitable for production use in the<br>
first place? And for today's wholesale margins?<br></blockquote><div>Here's the thing: even on those terms, it is worth it. For so many destinations (e.g. Central/Sub-Saharan Africa and such like), there really isn't much of a distinction between "reliable" wholesale routes and retail routes. You use the best you could to carry your traffic and my concern is for my retail customers. People like Vodafone, Orange and BT don't take too kindly to being FASed, and if you carry their traffic, then you by default are under contractual obligation to cushion the hit where they can prove a case. One case, for one of those routes that carry 250K minutes/day will bankrupt a small/medium carrier, even if you end up winning the legal argument.<br>
<br>What I'm trying to do is not make an unusable route usable. Rather, to detect an unusable route ASAP, place the terminating carrier on a very short leash, and disconnect them as early as possible should they re-offend.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
IMHO the best solution is policy:<br>
<br>
1) gather statistics from your CDRs (FreeSWITCH has lots of variables<br>
that you can use in your CDRs)<br>
2) place test calls in cases where the stats show a possible problem<br>
3) send a trouble ticket to the offending carrier in cases of FAS<br>
and<br>
4) stop using the route until the "problem" is fixed.<br>
<br></blockquote><div>I hear what you're saying. And how much is the time and man effort involved in manually dealing with this ?<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are "carriers" who give FAS issues all the time and you can't<br>
really deal with them... It's best to just avoid them completely after<br>
repeated FAS infractions.<br>
<br>
Best regards,<br>
<font color="#888888">Vlasis Hatzistavrou.<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ahmed Naji<br>