Freeze one call and define the unexpected answer
Record one affected call’s timestamp and timezone, caller and called identities, inbound or internal origin, exact ring-group number, strategy, ordered member list, ring time, intended human answer and actual endpoint or voicemail system that took the call. Preserve the group and downstream destination before changing any timer or member.
Distinguish a remote network answer, a voicemail greeting, a human press-to-accept result and the caller-to-callee bridge. A 200-class answer on an external leg can occur before a person accepts the business call, so “answered” is not one interchangeable event.
Prove the group and every generated member branch
Confirm the call entered the expected generated ring-group context, then compare the managed strategy and member order with the loaded dial attempt. A plain extension and an entry suffixed with # can select different paths; Sangoma documents the suffix for remote extensions, external numbers, Follow Me and other non-extension destinations.
For each branch, capture the dialed technology and resource, PJSIP endpoint or contact, any Local channel and whether the branch was created. Submit and Apply Config, generated dialplan, loaded runtime and a channel actually attempted during this call remain separate evidence stages.
Separate remote answer supervision from call confirmation
An external mobile or hosted voicemail service can answer the outbound leg before a person does. Sangoma documents Confirm Calls as a ringall-only control that requires the remote party to press 1 before the call is put through; Remote Announce and Too-Late Announce belong to that confirmation path.
Prove that the configured strategy supports confirmation, the remote announcement played, the expected DTMF reached the PBX and the acceptance arrived before another branch won or the group timed out. Do not turn confirmation on for every group as a generic repair: it changes the remote answering workflow and does not replace outbound-route, media or DTMF diagnosis.
Reconstruct the answer race and timer ownership
Build a branch timeline from channel creation through ringing or progress, remote answer, confirmation, bridge and hangup. ringall offers parallel channels, while hunt and memory-hunt strategies introduce ordered iterations; Sangoma documents Ring Time per iteration for hunt-style behavior. External provider or mobile voicemail timers are separate from the group timer.
Identify the first event that caused the group to stop offering other members. If nobody completed the intended answer path, follow the configured no-answer destination. Do not increase every timer until the branch that expires or answers first is known.
Explain cancelled siblings and phone indications
Asterisk Dial can offer several channels in parallel and the first accepted answer ends the remaining attempts. Record each branch result rather than interpreting a missed-call icon, short ring or “answered elsewhere” display as proof of which party answered. ANSWER, NOANSWER, BUSY, CHANUNAVAIL and CANCEL describe different dial outcomes.
FreePBX’s Mark Answered Elsewhere control and Asterisk’s cancellation cause can influence how losing devices present the call, but they do not establish that the winning branch was a human, voicemail or the correct member. Correlate the winning channel and bridge with the endpoint or external destination.
Correct one owner and retest every terminal path
Correct only the first demonstrated divergence: member syntax, strategy, member order, busy or forwarding policy, confirmation setting, recording selection, announcement, DTMF path, outbound route, remote voicemail timer, group timer or no-answer destination. Preserve prior values and rollback; use supported FreePBX controls rather than editing generated dialplan.
Retest with local members idle, one busy, one unreachable, the external destination answered by voicemail, a human accepting, a human declining or answering too late, another member winning and everyone unanswered. Confirm the intended bridge, cancelled branches, caller treatment and final destination. This workflow is documentation-derived and was not reproduced on a customer or laboratory system.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma: Ring Groups module user guide ↗
- Sangoma: Ring Groups module overview ↗
- FreePBX Ring Groups release/17.0 source ↗
- FreePBX Ring Groups release/17.0 metadata ↗
- Asterisk Dial application ↗
- Asterisk Dial channel variables ↗
- Asterisk: dialing PJSIP channels and contacts ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.