My dialplan includes an LCR algorithm for routing calls to one of five SIP termination providers. Currently, what I do is try to dial using the lowest cost provider and, if the response comes back with either “congested” or “channel unavailable”, I’ll continue to the next (more expensive) provider in the list. Any other response will cause the dialplan to break out of the loop and tell the caller to try later.
After an incident this morning, I’m wondering if I should treat “busy” responses in the same way that I treat “congested”. Assuming that a provider’s SIP server is returning the correct code for a given situation, should I expect to get “busy” for a particular number from all providers I try if one returns that status, or might it just be a problem at that provider?
It’s difficult to be entirely sure whether you have had a network problem or one at the final destination, but you should be using HANGUPCAUSE, not DIALSTATUS, as the latter has far too little detail.
Note this is is a discussion forum. You should use ones with “Support” in their name for questions on how to do things.
I’m aware of which forum this is, but the question seemed to me like less of an Asterisk-specific question and more one of dealing with SIP responses from other servers on the internet. Thanks for the pointer about using HANGUPCAUSE, though. More detailed information is always helpful in trying to figure out what to do.
According to the Asterisk console, I was getting a 486 (Busy Here) response from the provider in question. Looking at the SIP spec, that could either mean that the number is truly busy or is just not accepting the call from that particular provider, while the 600 (Busy Everywhere) response would seem to indicate that it’s pointless. HANGUPCAUSE appears to return the same code for both. There is the SIP_CAUSE hashmap, which apparently causes a performance hit, but on a system handling around 1-2 calls at a time I don’t know if that will be a big deal or not.
Busy here means that the destination doesn’t know that it is the only destination being tried.
However, I suspect that creative mappings between cause codes from different technologies will mean that you will never get a perfect solution.
You could look at the FreePBX source code to see what it considers fail-over-able conditions.