Hi, We need a way to alert management when the SIP-GSM gateway (in this case a 2N VoiceBlue) has run out of prepaid credit with the cellular carrier. (Don’t tell me to get a postpaid account, that’s not feasible here in Angola.)
It seemed “Monitor trunk failures” might be a mechanism but what we are actually seeing is:
[2012-12-14 13:19:25] VERBOSE[447] chan_sip.c: – Got SIP response 603 “Declined” back from 10.0.69.9:5060
[2012-12-14 13:19:25] VERBOSE[6803] app_dial.c: – SIP/voiceblue-000000a9 is busy
[2012-12-14 13:19:25] VERBOSE[6803] app_dial.c: == Everyone is busy/congested at this time (1:1/0/0)
[2012-12-14 13:19:25] VERBOSE[6803] pbx.c: – Executing [s@macro-dialout-trunk:23] NoOp(“SIP/529-000000a8”, “Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 21”) in new stack
HANGUPCAUSE 21 appears to be the correct equivalent for SIP 603 Declined. If we configure a second trunk, the system goes on and tries it which is OK but - that means we pay for a more costly route when what is really needed is to buy more credit for the line. Would “monitor trunk failures” catch this condition allowing an Email to be generated? Obviously we don’t want Emails for every call aimed at a busy destination… Or if the called user hits “reject”.
An old but relevant post by Philippe Lindheimer says:
“If the trunk fails for reasons such as CHANUAVAIL or CONGESTION, then the nest trunk is always tried. This assumes trunk providers are sending back the correct signalling though, as not all do. If the call fails because of BUSY it will not try the next trunk. The script is simply run if a failure mode is detected and upon returning it continues as always. A failure is considered anything that is not BUSY, NOANSWER, or CANCEL.”
Philippe seems to be saying that BUSY is not a failure and the Monitor script would NOT be run…
Might it be an Asterisk issue that “BUSY” is reported in this case?
We will much appreciate any guidance!