I know that there are quite a few error messages that one can get when placing a call through a SIP trunk. However, a 603 DECLINED or a BUSY should get FreePBX to move to the next trunk. It does NOT. I am using the latest 2.9x version and the moment I get SIP ERROR 603 DECLINED the call ends despite me having a secondary SIP trunk in the list of outbound trunks.
1- Can this be fixed? Is it in the works?
2- Is there a workaround for this?
I think all error codes should be somewhere in the settings and user should be given the option to route calls differently depending on the message received.
I recently had an issue where Vitelity was mysteriously sending 603 errors intermittently for a day or so. I can confirm my system (1.86.29.55-1) didn’t attempt the next trunk either. Unless I’m missing something it seems to me it should have. Is this a bug?
I use premium routing for international termination with Voip.ms. Voip.ms does not deliver calls to certain destinations using premium routing and they return a 603 Declined. Since Voip.ms was my primary outgoing trunk, the calls would busy out and never fail over to Vitelity or Flow Route. I have changed the trunk order to compensate, but there has to be a way to change the logic so that additional trunks are tried when a 603 is returned.
Yes, I had exactly same problem with iCall and others you mentioned. This is surely a bug in FreePBX and as I suggested above and will repeat below this can be a good fix:
All error codes should be somewhere in the General Settings and user should be given the option to route calls differently depending on the message received. So, these settings should be at admin’s mercy. I mean all SIP errors are known and well documented so it should be a relatively easy add-on feature.
Voip.ms, Flow Route, Vitelity. Are there any other good providers out there that accept minimum payments like these providers and provide good service?
FreePBX attempts to look at the DIALSTATUS and possibly the HANGUPCAUSE to determine what to do.
A trunk will not failover if the “conclusive” interpretation at the Asterisk level is that the end party can’t be reached.
An example of this is if it gets back the equivalent of a “BUSY” which means “this trunk got to them and they said they are busy” thus don’t keep trying other trunks just to hear the same news. There are other scenarios, such as I believe reporting it’s an invalid number.
The cases where it will try another trunk is when it gets back a report that “the trunk could not complete the call” but nothing conclusive about the status of the final destination since it could not get that far. This is the case when a trunk is CONGESTED for example, e.g. max channels are used up.
The problem is two fold. The SIP response codes are open to interpretation to begin with and don’t always map cleaning to HANGUPCAUSE codes, which are the codes that are better defined in PRIs for example and what gets mapped to the HANGUPCAUSE. The second issue is that some providers make poor choices or outright incorrect choices as to what to return in their SIP response code.
We’ve tried to get more granular over time by looking at the HANGUPCAUSE. We used to JUST look at the DIALSTATUS and if it was CONGESTION we gave up.
On modern versions of FreePBX (2.9 for example but probably still the case for 2.8), according the a quick web search (which may be wrong), 603 translates to a HANGUPCAUSE of 21. According to a quick check of the dialplan generated, 21 falls into the “_X.” bucket of hangup causes which continues to the next trunk.
So, either you have a dated (and/or unsupported) version of FreePBX (you didn’t mention what you were running which always helps), or a different HANGUPCAUSE is being returned. If you have a modern supported version of FreePBX, post what your HANGUPCAUSE is coming back as to see if there is an issue either in Asterisk or FreePBX.
I and others who posted here are all running FreePBX 2.9.0.7.
I agree with you that SIP error codes are open to intrepretation and ISTPs don’t even regard it properly. So, the best solution for FreePBX is to allow to move to next trunk REGARDLESS of the error (of course except in case of ANSWER). Please make this an option in the settings. That way, you can carry on with fine tuning and finding what is congestion or not (until everyone agrees on it) and in the mean-while everyone else can be happy and decide for themselves to send call to another trunk or not.
Personally and I am sure this applies to others as well, even if it’s a true busy, I still don’t mind trying a second trunk. Reason for that is because customer satisfaction is the most important thing or placing the call is the most important thing. It’s okay to waste some electrons in the process.
I will try to post the CLI output and SIP debug but based on what you said it seems like there is a bug in the FreePBX code if it doesn’t failover when a 603 comes.
Now that you put it out in the open I feel the need to comment and point something out that Philippe can’t in his position.
You used the phrase “customer satisfaction is the most important” to me this implies you are using FreePBX in some type of shared or maybe even in a group tandem type function as a trunking server to other sub-tended boxes. This is not what FreePBX was designed for. It has been repeatedly stated that FreePBX is not even suitable for this type of application. Development resources are not going to be used to add features to make it easier to use FreePBX in non-intended applications.
If you have a revenue model why not support the project and engage some developers to add this feature? This is a great way to give back to the project and support this incredible platform.
Unless I am missing something when would this be an issue in a PBX environment serving once customer?
As an ITSP that uses open source technology I fully understand ill behaved downstream providers. Asterisk can be programmed to handle these situations. If you look you will find that Freeswitch is even more flexible. If it support IAX I would be running it today.
Before you jump your guns, I should tell you that you are pointing the obvious. Everyone is either using this product for personal or commercial gain. In return people report bugs and help improve the product. Don’t take the high moral ground and tell me I said the word “customer”. I know what I said and I said it for a reason to help improve FreePBX and not to show frustration. If you are part of the FreePBX team, this is not the way to ask for donations. If not part of the team then I am at total loss of words.
Regardless, this has to be established to be a bug by collecting evidence. This is not a philosophical issue and no need for any other talk than finding the bug (if there is one). Keep your lectures and thoughts to yourself. I may sound harsh but for others understanding let me say that you have a record of provoking people on this forum and other forums.
Donations? FreePBX team doesn’t ask or I even believe accept cash donations now that the site has a corporate sponsor.
My intent is not to draw attention to my contributions, if you are interested in meeting some of the people behind the project (including myself) come to Naples for the training, join us at Astricon, Philippe was at an Atlanta users group meeting and I will be at one this year. Lot’s of opportunities to meet.
Provoking causes discourse and discussion. It’s not personal.
Certainly FreePBX is to be deployed in businesses, that’s primary use. My beef is with resellers and worse “hosted” PBX providers that try and hack together an offering using FreePBX. Essentially you are asking the team and other users to help you solve issues that you are being compensated to resolve. It’s unreasonable.
you are jumping the gun by suggesting that there should be an option to roll over to the next trunk since your situation should be returning a response code that does that anyhow.
I still haven’t seen a dialplan trace that answers the questions above so we can see if a bug needs to be filed on this or not.
As far as making options to skip to the next trunk anyhow, there are negative consequences in doing this at times so it has not been a desired mode. Ideally Asterisk would present an ability to send back the SIP code in addition to the HANGUPCAUSE so we can provide smarter decisions like we have tried with the HANGUPCAUSE.
It’s been suggested that we enhance the Outbound Route Messages module to add further control of what happens on different hangup causes (and SIP responses if we could get that). It’s a reasonable thing to do though there are probably a lot of other features that will probably continue to push that suggestion lower on the list.
Again though … the 603 should be continuing so getting the requested details will help determine what’s going on.
The 603 ‘Declined’ is being translated into a BUSY status, which macro-dialout-trunk is killing so it doesn’t make it through the rest of the outrt-* defined trunks.
With voicemail and call waiting today I question how often you would legitimately get a busy signal, but even if one did occur each outbound route already ends with Macro(outisbusy,1).
The default dialplan sequence from macro-dialout-trunk is:
================
exten => s-BUSY,1,Noop(Dial failed due to trunk reporting BUSY - giving up)
exten => s-BUSY,n,Playtones(busy)
exten => s-BUSY,n,Busy(20)
To work around this in the meantime, you can just add the following lines into extensions_override_freepbx.conf:
=================
[macro-dialout-trunk]
exten => s-BUSY,1,Goto(700)
exten => s-BUSY,700,Noop(Dial failed due to trunk reporting BUSY - failing through to other trunks)
This change will make it so that if macro-dialout-trunk ends with a trunk reporting a status that translates to busy, it will skip over the dialplan lines that FreePBX inserts to stop trying and play a busy signal, and will allow the macro to complete and return to outrt-* where the next trunk can be attempted.
=================
[macro-dialout-trunk]
exten => s-BUSY,1,Goto(700)
exten => s-BUSY,700,Noop(Dial failed due to trunk reporting BUSY - failing through to other trunks)
This is wrong. Using this workaround the MOH stops when dialing next trunk.
I’m using the following in extensions_override_freepbx.conf to work as expected and in the logical way:
FreePBX doesn’t check HANGUPCAUSE when DIALSTATUS returns BUSY. Below is the trace requested for a SIP response of 603. This is running on FreePBX 2.9.0.12 and Asterisk 1.8.
– Called SIP/zzzzzzzzz/XXXXXXXXXX
– Got SIP response 603 “Declined” back from XXX.XXX.XXX.XXX:5060
– SIP/ zzzzzzzzz -0000002d is busy
== Everyone is busy/congested at this time (1:1/0/0)
– Executing [s@macro-dialout-trunk:21] NoOp(“SIP/101-0000002c”, “Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 21”) in new stack
– Executing [s@macro-dialout-trunk:22] Goto(“SIP/101-0000002c”, “s-BUSY,1”) in new stack
– Goto (macro-dialout-trunk,s-BUSY,1)
– Executing [s-BUSY@macro-dialout-trunk:1] NoOp(“SIP/101-0000002c”, “Dial failed due to trunk reporting BUSY - giving up”) in new stack
– Executing [s-BUSY@macro-dialout-trunk:2] PlayTones(“SIP/101-0000002c”, “busy”) in new stack
– Executing [s-BUSY@macro-dialout-trunk:3] Busy(“SIP/101-0000002c”, “20”) in new stack
== Spawn extension (macro-dialout-trunk, s-BUSY, 3) exited non-zero on ‘SIP/101-0000002c’ in macro ‘dialout-trunk’
== Spawn extension (from-internal, XXXXXXXXXX, 5) exited non-zero on ‘SIP/101-0000002c’
– Executing [h@from-internal:1] Hangup(“SIP/101-0000002c”, “”) in new stack
== Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/101-0000002c’
SkykingOH and p_lindheimer, others did post the issue but there was no constructive response from you. Sounds like you are beating around the bush for money when you should take the responses seriously. I find this to be a really cheap tactic. Please keep the forum professional.
FreePBX is simply not able to read hangup cause and that is a real issue because failover trunk never works without knowing the cause code and it’s a dormant feature.
p_lindheimer: also you should know that there are many providers that return many different codes like 603, 503, 489, etc…but in this wild west world of international calling all these codes are not reliable. The option to move onto next trunk is needed and is asked for international dialing. Please revise your decision on the ticket that fiftyz took the time to identify: http://www.freepbx.org/trac/ticket/5862