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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org