VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
webaccounts at jgoettg...
Guest
|
 Posted: Tue Dec 17, 2013 1:19 pm Post subject: [asterisk-users] 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
--
_____________________________________________________________________
-- 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 |
|
| Back to top |
|
 |
rmudgett at digium.com
Guest
|
| Posted: Tue Dec 17, 2013 2:41 pm Post subject: [asterisk-users] Who causes the congestion or can I mix? |
|
|
On Tue, Dec 17, 2013 at 12:19 PM, jg <webaccounts@jgoettgens.de (webaccounts@jgoettgens.de)> wrote:
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
webaccounts at jgoettg...
Guest
|
| Posted: Tue Dec 17, 2013 3:54 pm Post subject: [asterisk-users] Who causes the congestion or can I mix? |
|
|
| Quote: | Look at the HANGUPCAUSE function.
|
I forgot about that one. Too many variables to remember.
| Quote: | 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).
| Quote: | 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 |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
