Content
# #laguna — 2026-03-26
**15:16 [Kevin](https://slack.com/archives/C08JS6KDLBD/p1774563361032619):** @Mason Radke Jerry called and said TopView is doing strange things.
**15:42 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774564948716749):** Ok
**15:43 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774564992614079):** Any details on what that means?
**16:56 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774569372062739):** do they have a test alarm that goes out each day?
**16:56 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774569378977629):** for callout?
**17:32 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774571567704539):** there is something going on with the grandstreams maybe..
**17:32 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774571577870459):** do you have the logins? i dont see them in evernote or the vault
**17:33 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774571591829709):** i see a primary and secondary grandstream device
**17:33 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774571599101519):** @Kevin
**18:00 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573248260089):**
*Primary SIP trunk (10.15.10.42) is the problem.* After 3/19, calls through it return *SIP error 480 (Temporarily Unavailable)*, especially to cell phones.
TopView fails over to a secondary trunk (10.15.10.43) which works — so calls eventually go through, but with delays and logged failures.
**18:01 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573278331719):**
```
he Grandstream UCM6202 PBX at 10.15.10.42 is processing calls correctly — SIP registration and INVITE auth
always succeed. The 480 errors are coming from downstream (the SIP trunk/PSTN side), with Q.850 cause codes indicating busy lines, no answer, and no
circuits available.
The failures are intermittent — 17 successes vs 79 failures on 3/26 alone — which points toward a trunk capacity or routing issue rather than a total
misconfiguration
```
**18:09 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573761723609):** i figured it out.
**18:09 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573765352549):** it was my fault.
**18:09 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573787344159):** topview is actually running on a different server.
**18:10 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573814307859):** so when i set it to automatic and started the service on this server it began making calls to the grandstreams at the same time..
**18:10 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573818305639):** causing timeouts, and failures
**18:10 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573833561539):** i disabled this service and set it back to manual.
**18:10 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573842898189):** confirmed that its automatic on the OTHER vm
**18:10 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573859649919):** i'll need to make sure our alarm changes are running on the primary topview server.
**18:11 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573890553219):** for our notes: topview's primary server is APP-SRVR2
**18:11 [Mason Radke](https://slack.com/archives/C08JS6KDLBD/p1774573901046149):** APP-SRVR1 is topviews backup server
**18:29 [AutoBot](https://slack.com/archives/C08JS6KDLBD/p1774574956476739):**
*TopView SIP Call Failure — Root Cause & Recommendations*
*Root Cause:*
Starting 3/19, both APP-SRVR1 and APP-SRVR2 were running the TopView engine simultaneously, both registering as SIP extension 1003 on the Grandstream UCM6202 PBX. This caused a SIP registration conflict — the two servers competed for the same extension, resulting in intermittent SIP 480 "Temporarily Unavailable" errors on alarm call-outs. The engine on APP-SRVR1 had been dormant since 1/1/2025 and was manually started on 3/19 without stopping APP-SRVR2.
*Resolution applied:* Stopped TopView engine on APP-SRVR1, set back to Manual start. APP-SRVR2 continues as sole active server.
*Failover Architecture Recommendations:*
1. *Configure WatchDog Engine* on APP-SRVR1 — monitors APP-SRVR2's health and only starts the local engine if the primary goes down. Prevents dual-engine operation.
2. *Shared DataPath* — move TopView config to a shared network path so both servers use identical configuration. The failover license supports this.
3. *Unique SIP extensions* — assign different extensions per server (e.g., 1003 for APP-SRVR2, 1004 for APP-SRVR1) to prevent registration conflicts if both are ever running.
4. *Document the architecture* — create a runbook for primary vs. failover roles, manual failover procedure, and SIP extension assignments.
Full report available — reach out to Mason for the detailed .docx with complete log analysis.