<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 17, 2013 at 12:19 PM, jg <span dir="ltr"><<a href="mailto:webaccounts@jgoettgens.de" target="_blank">webaccounts@jgoettgens.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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).<br>
</blockquote><div><div><br></div><div>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.<br>
</div><div> <br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>

<br>
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.<br>
<br>
In chan_dahdi.conf there would be something like<br>
<br>
context=from-pstn-p2p<br>
group=2<br>
signalling=bri_cpe<br>
channel =>1-2<br>
<br>
context=from-pstn-p2p<br>
group=2<br>
signalling=bri_cpe<br>
channel =>4-5<br>
<br>
context=from-pstn-p2p<br>
group=2<br>
signalling=bri_cpe<br>
channel =>7-8<br>
<br>
context=from-pstn-p2mp<br>
group=2<br>
signalling=bri_cpe_ptmp<br>
channel =>10-11<br>
<br>
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.<br>
<br>
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.<span class=""><font color="#888888"><br></font></span></blockquote><div><br>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.<br>
<br>Richard<br></div></div></div></div>