[Freeswitch-users] FAS detection with FS

Ahmed Naji a.alalousi at gmail.com
Fri Jan 8 13:57:16 PST 2010


Hi Vasilis,

Good points .. my comments inline.

Regards,

Ahmed.

2010/1/8 Vlasis Hatzistavrou (KTI) <vhatz at kinetix.gr>

> Hello Ahmed,
>
> On 8/1/10 6:07 μμ, Ahmed Naji wrote:
> > My line of thought is to tone-detect secondary ringing tones post
> > 200(OK) to detect FAS (False Answer Supervision). This should
> > eliminate at least a good proportion of calls, and it can be done real
> > time through a script/modules/...etc.
> >
>
> Tone detection can work only in cases where actual tones are sent over
> the audio. There are some routes (especially mobile routes) where
> different ringtones or music can be used instead of ringback tones,
> which render the whole tone detection effort difficult. There are also
> cases where no audio at all is sent until the called party answers the
> phone. Not to mention that the "FASed" route's behavior can change over
> time, rendering an effort for permanent FAS detection futile.
>
> 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.

> Working along this thought, at least you are minimising the hit
> > cost-wise to a few seconds at most.
>
> Well, even if you manage to detect FAS given to you by your termination
> provider, you cannot really minimize loss, as typically calls are
> charged by the time difference between 200(OK) and BYE.

True, but the idea is to minimise this duration, and hangup the call ASAP.

You can't really
> dispute anything even if you manage to detect FAS in real time, because
> you cannot prove this in a court or to anyone else by presenting CDRs
> only. You can't really pinpoint in a list of calls which ones had FAS.
> And of course, the terminating partner who gives FAS will deny it most
> of the times.
>
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.


>
> >
> > As to answering machines and fake conferences, fake network messages
> > ...etc, one can possibly use voice detection, perhaps with heuristic
> > and statistical training.
>
> You will need to combine tones detection, music detection, answering
> machine detection, which in the end makes the whole effort pointless.
>
Debatable. Hard, yes, but pointless ? I don't really agree.


> You will need to use DSP in software or in hardware to even try
> accomplish this (which means additional cost),

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.


> and for what? For trying
> to detect FAS on a route which is not suitable for production use in the
> first place? And for today's wholesale margins?
>
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.

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.


> IMHO the best solution is policy:
>
> 1) gather statistics from your CDRs (FreeSWITCH has lots of variables
> that you can use in your CDRs)
> 2) place test calls in cases where the stats show a possible problem
> 3) send a trouble ticket to the offending carrier in cases of FAS
> and
> 4) stop using the route until the "problem" is fixed.
>
> I hear what you're saying. And how much is the time and man effort involved
in manually dealing with this ?


> There are "carriers" who give FAS issues all the time and you can't
> really deal with them... It's best to just avoid them completely after
> repeated FAS infractions.
>
> Best regards,
> Vlasis Hatzistavrou.
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>



-- 
Ahmed Naji
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100108/cfc4016c/attachment-0002.html 


More information about the FreeSWITCH-users mailing list