- Shipped
- August 27, 2026 at 2:23 AM UTC
- Author
- Kamo
- Commit
- e4b4957
Eight hold tracks uploaded as the `kamocrm-hold` MOH class, shuffled. The random ordering comes from `random=1` on the row in FreePBX's `music` table, which is what generates `sort=random` into musiconhold_additional.conf — set it in the DB, not in the conf, or the next FreePBX reload overwrites it. Routing after the greeting: extension -> forwarded to that extension (unchanged) 1 or 2 -> queue timeout -> queue bad exten -> "invalid" prompt, then queue The queue is **************** in a loop, so both ring at once, first to answer wins, and the caller hears hold music instead of ringback throughout. Members are dialled as raw PJSIP endpoints rather than through from-did-direct ON PURPOSE: going through FreePBX's extension dialplan would apply each extension's ring timer and then hand the caller to that person's voicemail, which is the opposite of ringing indefinitely. The loop has no cap, as requested. The guard that matters is the ExecIf: only NOANSWER means we really rang for the full timeout. CHANUNAVAIL (nobody registered), CONGESTION and BUSY all return in milliseconds, so without a MusicOnHold pause the Goto becomes a tight spin. Measured with both members deregistered: 1 second of CPU and 24 log lines across 45 seconds in queue. Also raises WaitExten's grace window to play hold music, so the handover from greeting to queue has no silent gap. Verified live: PJSIP/8080 observed in Ringing state under **************** with the caller channel in Ring. Audio is not in the ConfigMap — greeting 1.1 MB plus 7.7 MB of tracks is well past the etcd object limit. Both sets live on the asterisk-lib hostPath and the conversion command is documented beside the globals that name them.