asterisk users - Dec 2013 - Who causes the congestion or can I mix?

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.

jg

On Tue, Dec 17, 2013 at 12:19 PM, jg <webaccounts at jgoettgens.de> wrote:
> 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).
>
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.

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

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20131217/a0b82c87/attachment.html>