I’m running FreePBX 14.0.1.1 and Asterisk 13.17.0 and seeing some odd behavior with a ring group. The group has just two members one is an internal extension (1010) and the other is an outside phone number. The confirm calls option is set to yes.
When a call comes into the ring group the phones will ring as expected. If i answer before the 15 second ring timeout I get the call confirm and its acts normally. If i do not answer the call rings and the stops for a split second (or if i ignore the call on both phones, after the 15 second ring timeout) both phones start ringing again. This time if i answer it’s a direct connection no confirmation needed and if i don’t answer the external cell phone’s voicemail grabs the call.
Anyone else seen this kind of behavior?
What logs might I have that would be helpful to dig deeper?
If i remove the external number from the ring group, and dial the ring group extension (testing by dialing from another internal extension not involved in the ring group). The destination internal extension will ring, and when answered does not require the call confirm it direct connects immediately. If the call is not answered the call just disconnects it does not follow the no answer destination.
If i remove the internal extension from the group and only have the external number the call rings, and if answered does the call confirmation. If the call is not answered the external number stops and then immediately starts ringing again, and is then eventually answered by the voicemail on the external extension with no call confirmation.
In the asterisk log it shows where the 15 second timeout happens
-- Nobody picked up in 15000 ms
-- Executing [s@macro-dial:22] Set("PJSIP/1012-000001a7", "DIALSTATUS=NOANSWER") in new stack
-- Executing [s@macro-dial:23] GosubIf("PJSIP/1012-000001a7", "0?NOANSWER,1()") in new stack
-- Executing [s@macro-dial:24] NoOp("PJSIP/1012-000001a7", "Returning since nobody answered") in new stack
-- Executing [s@macro-dial:25] MacroExit("PJSIP/1012-000001a7", "") in new stack
but then just dives right back into spawning the call again. The same setup used to work on Freepbx 13 so i’m sure i am just doing something incorrectly in the new version but i am not sure what. Its just as if the no answer destination is being completely ignored.