[Freeswitch-users] False Answer Supervision (FAS) - Question

Alfredo Quiroga-Villamil lawwton at gmail.com
Mon Apr 12 10:23:34 PDT 2010


Thanks for the response Vlasis. We run statistical analysis for FAS in
our production routes.

This request would be for a controlled environment where I am using
GrandStreams 488 to convert from Voip to PSTN. I was thinking that
perhaps FS has a way to allow me somehow access to the Signaling
portion of the protocol. If that was the case, I would be able to hack
my way around it and perhaps ignore the first 200 I receive and not
propagate it to the origination gateway. This is the setup I am
looking at:

A => B => GrandStream Device => PSTN

   SIP   SIP

A/B - Both Gateways

This is a test environment I am using, something I am just playing
with. So in every case I will receive a FAS from the GrandStream
device.

Do you know if there is a way to launch an application from the
DialPlan and have access to intercept Signaling; something that would
allow me to see the messages coming in and make decisions based on
them like propagate or do not propagate that message. I know this is a
tough thing since I am literally asking for access to the SIP Stack.

Thanks,

Alfredo

On Mon, Apr 12, 2010 at 12:22 PM, Vlasis Hatzistavrou (KTI)
<vhatz at kinetix.gr> wrote:
> Hello Alfredo,
>
> Please see comments inline:
>
> On 10/4/10 6:51 μμ, Alfredo Quiroga-Villamil wrote:
>> All:
>>
>> A while back I tried to solve a false answer supervision issue I was
>> intermittently receiving from underlying carriers. Back then I tried
>> to find a solution using asterisk but had other pending things and put
>> this off until now.
>>
>> Does anyone have any recommendations on how to possibly handle or get
>> around FAS using FS. If I am not mistaken what would be needed is to
>> have something that upon receiving the first 200 message, it simply
>> ignores it, never propagating it and waits for the next 200. I can
>> control this now a little bit better since it's only happening when
>> the calls are sent to a couple of GrandStreams (FXO).
>>
> As you have already noticed, when you get FAS, you receive a 200 before
> the call is answered. But I have never seen a second 200 when the call
> is really answered by the remote end, because after you receive the
> first (and only) 200 message, the call is considered as being properly
> connected, with RTP going both ways and all. A FAS giving carrier will
> take care to not send you another 200 when the call is answered.
>
> So, I don't believe there is a way to detect and remove FAS
> successfully, because to your equipment, it just looks like a properly
> answered call. What you can do is gather batches of CDRs and extract
> statistics about the time delay from the INVITE you send to the 200 you
> receive. If you measure it too short, then you PROBABLY have FAS, and
> you'd still need to place a test call yourself you verify it.
>
> You will not be able of course to tell which exact calls had FAS, but
> you'll be able to have a clue about whether there is FAS present on the
> route or not. And this means that you'd still have to do a lot of work
> yourself, like watching stats, placing test calls etc.
>
> Even if you were able to find a way to remove FAS on a route, that would
> mean that your termination carrier would still charge you for the time
> difference between the 200 that he sends you and the BYE. And you'd
> still pay for a longer duration than what you would charge to your
> customer if you were able to remove FAS.
>
> This is why my opinion is to watch statistics, place test calls and in
> the event of a carrier giving FAS, remove it from your routing. Sooner
> or later, they will either stop giving you FAS or you will stop doing
> business with them.
>
>
> Best regards & good luck,
> 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
>



More information about the FreeSWITCH-users mailing list