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). My idea is to perhaps write a little application and add it to the DialPlan. The little script/app. would have the logic to ignore the first 200 and hopefully get around this issue. Is that something that is doable? Any other ideas on how to do this assuming is even possible to do it? Thanks in advance, Alfredo
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.
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
2010/4/12 Alfredo Quiroga-Villamil <lawwton@gmail.com>
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.
I think those last two sentences describe a natural feature of a SIP proxy. I'd check out OpenSIPS to see if it has the stack-level control and functionality that you need. -MC
Thanks Michael. Indeed, OpenSips has exactly what I need in this case. Appreciate the response. Alfredo On Mon, Apr 12, 2010 at 7:48 PM, Michael Collins <msc@freeswitch.org> wrote:
2010/4/12 Alfredo Quiroga-Villamil <lawwton@gmail.com>
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.
I think those last two sentences describe a natural feature of a SIP proxy. I'd check out OpenSIPS to see if it has the stack-level control and functionality that you need. -MC
_______________________________________________ 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
Hello Alfredo, On 12/4/10 8:23 μμ, Alfredo Quiroga-Villamil wrote:
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:
Are you absolutely certain that when your carrier (or test rig) gives FAS you receive two 200 messages instead of one? Have you verified it using Wireshark captures?
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.
Perhaps there is a way to create an app to detect when a SIP 200 message arrives, but I still have reservations whether 2 such messages arrive... I'd like to help you in this, so, do you have a packet capture file to share where 2 200 SIP messaes are sent? Regards, Vlasis.
Hello Vlasis. I'll set something up this afternoon and send it to you to make sure I am interpreting this correctly. Essentially the issue I am experiencing in this case seems to be due to the VOIP ==> PSTN conversion being done by the GrandStream. I wasn't really using wireshark; just looking at the SIP trace after having enabled SIP debug messages. I'll setup a test today and capture the output of it and send it your way. If I am not mistaken what I am seeing is a 200 OK message being sent by the GrandStream immediately after doing the bridge from the VOIP leg to the PSTN side. Once the bridge is created and the call sent over the PSTN, if an answer is received, the GrandStream will then propagate a second 200. A second set of eyes wouldn't hurt before I try to implement a hack for this using OpenSips. In this case I seem to have the ability as Michael previously pointed out to intercept Signaling and manipulate it if needed. The basic idea I have is since I will always receive a 200 OK, (assuming I was correctly looking that day at the SIP trace) is to simply ignore the first one and propagate just the second one received. Which could also be a 486 or whatever other message. At that point I wouldn't care, I would just propagate whatever I get after the first 200. I really appreciate the help with this since this could be a tricky issue at times. Simplified in this case since I will always receive the same result. Alfredo 2010/4/13 Vlasis Hatzistavrou (KTI) <vhatz@kinetix.gr>:
Hello Alfredo,
On 12/4/10 8:23 μμ, Alfredo Quiroga-Villamil wrote:
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:
Are you absolutely certain that when your carrier (or test rig) gives FAS you receive two 200 messages instead of one? Have you verified it using Wireshark captures?
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.
Perhaps there is a way to create an app to detect when a SIP 200 message arrives, but I still have reservations whether 2 such messages arrive... I'd like to help you in this, so, do you have a packet capture file to share where 2 200 SIP messaes are sent?
Regards, Vlasis.
_______________________________________________ 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
participants (3)
-
Alfredo Quiroga-Villamil
-
Michael Collins
-
Vlasis Hatzistavrou (KTI)