John Lind

Made backups after tweaking a couple of the system recordings. When I do that I always check for module updates before running the backup in the admin GUI. Noted the SIP Settings module was one of the two. If that was your doing, thanks.

Noel, Yes, one of the things I did was a CLI "Core Restart Now" command, which forces an immediate Asterisk restart. All the pjSIP extensions were back on line in well under a minute. The phenomenon I experienced shouldn't be related to my network structure. Detectable latency unaided without measuring tools is nil. I've been able to toggle the problem on and off with that one setting (the definitive method of proving root cause has been identified). I've been posting the journey here so that other...

Noel, Yes, one of the things I did was a CLI "Core Restart Now" command, which forces an immediate Asterisk restart. All the pjSIP extensions were back on line in well under a minute. The phenomenon I experienced shouldn't be related to my network structure. Detectable latency unaided without measuring tools is nil. I've been able to toggle the problem on and off with that one setting (the definitive method of proving root cause has been identified). I've been posting the journey here so that other...

Noel, Yes, one of the things I did was a CLI "Core Restart Now" command, which forces an immediate Asterisk restart. All the pjSIP extensions were back on line in well under a minute. The phenomenon I experienced shouldn't be related to my network structure. Detectable latency unaided without measuring tools is nil. I've been able to toggle the problem on and off with that one setting (the definitive method of proving root cause has been identified). I've been posting the journey here so that other...

Noel, Yes, one of the things I did was a CLI "Core Restart Now" command, which forces an immediate Asterisk restart. All the pjSIP extensions were back on line in well under a minute. The phenomenon I experienced shouldn't be related to my network structure. Detectable latency unaided without measuring tools is nil. I've been able to toggle the problem on and off with that one setting (the definitive method of proving root cause has been identified). I've been posting the journey here so that other...

Solved "Apply Config" throwing all pjSIP endpoints (extensions) offline for 30-40 minutes . . . Additional Google search led me to suspecting a default Asterisk SIP setting for pjSIP (under that tab). The "Allow Transport Reload" was defaulted to "ON". Turned it "OFF" and tried several "Submit" followed by "Apply Config" in various configuration areas. No longer boots the pjSIP endpoints offline. This solution wasn't entirely clear in some of the discussion about it I found elsewhere - which also...

Doing it all manually from scratch for four DIDs on one VoIP provider trunk, plus two PSTN lines (on FXS/FXO ATA boxes) with their own trunks, spanning nine extensions, was the painful part - including setting up the user accounts for the nine extensions and porting over their absent/busy greetings. The goal was making the switch seamless, or as seamless as possible (call histories, stored VMs and call recordings aren't there - yet). General flow is about the same among all four, and very similar...

I'll try this fix with a backup Pi 3B+ programmed with the beta for testing it. The Pi 4B appears to be stable enough that I'm going to put it online with the phones for a few days to test it under a light load for a shakedown cruise. Programming the existing system into it was time consuming as I've got two sets of time conditions driving multiple IVRs and ring groups to handle four DIDs for four different and unique activities with their own names and identities. It's not a straightfoward inbound...