Who Causes The Congestion Or Can I Mix?

Home » Asterisk Users » Who Causes The Congestion Or Can I Mix?
Asterisk Users 2 Comments

Is there a recommended way to find out the cause of DIALSTATUS = CONGESTION for PRI/BRI
channels? Currently I am evaluating the DIALSTATUS variable and I also count the active ISDN
channels for the ISDN trunk in question. Counting the active ISDN channels seems somewhat clumsy as the mapping to a specific trunk must be done by hand (or write even more code).

I have a setup where outgoing calls normally use a P2P trunk, but if there are no free channels the system tries a separate P2MP trunk. In case the congestion is caused by the called party, switching to another trunks does not make any sense, so I need to find out whether my side is causing the CONGESTION.

Has somebody tried to setup a dialgroup where P2P, P2MP, and POTS devices are all part of the same group? This would also solve my problem.

In chan_dahdi.conf there would be something like

context=from-pstn-p2p group=2
signalling=bri_cpe channel =>1-2

context=from-pstn-p2p group=2
signalling=bri_cpe channel =>4-5

context=from-pstn-p2p group=2
signalling=bri_cpe channel =>7-8

context=from-pstn-p2mp group=2
signalling=bri_cpe_ptmp channel =>10-11

which mixes 2 P2P (4 voice channels) and 1 P2MP (2 voice channels). There would be different contexts for incoming calls, but DIAL(DAHDI/g2/…) could pick any of the 6 channels for outside calls.

This looks odd, but I don’t see any reason why it should not work or whether I might get in trouble with the telco, or crash Asterisk.


2 thoughts on - Who Causes The Congestion Or Can I Mix?

  • Look at the HANGUPCAUSE function. 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.

    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 forgot about that one. Too many variables to remember.

    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).

    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.