Look at the HANGUPCAUSE function.
I forgot about that one. Too many variables to remember.
A congestion cause does not necessarily mean that the congestion is in the link between you
and the network. It could be from any link between you and the destination.
Exactly, and I need to filter out some of these causes. The congestion may also be signaled by
the called party, or even the telco may have a problem (but not where I live, I swear).
This kind of grouping does work for the initial channel selection. However, glare from an
incoming call wanting the same channel could still get you a congestion status even though
another span has channels available. Be aware that chan_dahdi sorts the group by channel
number so the g2 channel search will always start with the lowest channel number.
I always use something like r2. This allows me to easier detect problems with the "network
termination unit" (NTBA), but this is off-topic. If I understand you correctly, there can be
rare cases where I could end up with a CONGESTION state due to things needing a finite time for
several states, but in reality there could still be free channels on either the same span or on
a different one. Then the RetryDial() application would make sense to me for the first time.
Essentially, there could be something like a deadlock situation which could cause a call to fail
unnecessarily.
So, putting everything available for calling outwards into a single group and using RetryDial()
might be a practical approach. The setup I am looking at has about 800 calls during business
hours for 4 P2P + 2 P2MP channels.
jg
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
