VoIP.info Troubleshooting

Asterisk channel-group count is wrong or a call limit is bypassed

Trace one admission decision through the selected channel, exact group and category, count timing, created legs, Local-channel optimization, transfer and teardown before changing a threshold.

Reviewed 2026-10-19Asterisk Latest API GROUP, GROUP_COUNT, GROUP_LIST and GROUP_MATCH_COUNT references generated from branch 23, channel architecture, variable-inheritance and Local-channel optimization documentation reviewed October 12, 2026; a group count is local channel state rather than a provider entitlement or complete call count, and no PBX, dialplan, group, channel, bridge, trunk, account, call, limit or denial was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one decision and classify the first mismatch

Record timestamp and timezone, Asterisk version, source and loaded dialplan, selected route, threshold, expected counted object, group, category, channel name, unique ID, linked identifier and observed decision. Classify the symptom: count too low, count too high, unrelated traffic included, limit branch skipped, call denied below the threshold, or membership retained longer than expected.

Preserve logs and channel inventory before reloading dialplan or raising the threshold. A carrier rejection above its allowance is not proof that the local group count failed, and a local denial is not proof that provider capacity was exhausted.

Prove the loaded group key and comparison

Follow the actual priorities to the GROUP(category) assignment and the exact GROUP_COUNT(group@category) or GROUP_MATCH_COUNT() expression. Confirm case, whitespace, expansion, regular-expression scope, comparison operator and whether the current channel joins before or after the read. A correct source file or GUI value does not prove the running dialplan loaded it.

For a pattern count, test the group and category expressions against the intended names only. Correct an over-broad or under-matching expression before changing the numeric limit.

Inventory the channels represented by the number

At the failed instant, list every channel in the matching group and map it to an inbound leg, outbound attempt, Local half, transferred leg, callback, originated channel or other service path. Use GROUP_LIST() on candidate channels to confirm their memberships. One call can own multiple channels, and one channel can hold one group in each of several categories.

Do not deduplicate solely by linked identifier: the policy may intentionally count an outbound attempt per channel, while a conversation-level policy may need a different owner. Reconcile the design first, then identify duplicate or missing membership.

Trace creation, inheritance and Local optimization

Mark where Dial(), Originate, transfer or a Local channel creates each new leg. Record inherited variables separately from actual group membership. If a Local pair optimizes away, identify the surviving channels and the exact moment the count changes; if /n is present, verify that retaining the pair is intentional.

A value copied with _NAME or __NAME can help identify a policy, but it is not evidence that the child joined GROUP(category). Do not add inheritance prefixes or disable optimization until the first missing owner is proved.

Follow rejection and teardown without manufacturing capacity

When the guard rejects a channel, confirm the count included or excluded that current channel as designed and that the at-limit branch produced the documented outcome. For accepted calls, continue through ringing, answer, bridge, transfer and hangup until the selected member channels are destroyed and the count falls.

A stuck high count may instead be a still-live channel, long teardown path or a different matching group. A low count may reflect assignment after the decision, assignment to the wrong leg, early destruction or a name mismatch. Do not terminate channels merely to make the number look right without first identifying their service role.

Correct one ownership boundary and retest a matrix

Correct only the first demonstrated defect: loaded dialplan, group or category key, pattern, channel owner, assignment timing, comparison, Local-channel design or teardown path. Preserve the previous dialplan and a rollback.

Retest below, at and above the threshold; answer, no-answer, busy and cancel; transfer and Local-channel paths in scope; parallel arrivals; abnormal teardown; unrelated tenants; and provider-side behavior separately. This diagnostic is documentation-derived and was not reproduced on an installed or laboratory Asterisk system.

Switch diagnostics when the disputed object is a dial list

If the symptom concerns which targets were passed to Dial rather than a live-channel count, use the DIALGROUP diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.