Skip to main content

​
Voice Go-Live Weekend

Three checklists already cover the gates: the platform-wide production go-live checklist, the PSTN voice go-live checklist (numbers, identity, routing, recording, compliance), and the contact-center go-live runbook (softphone, queues, IVR, cutover). None of them answers “what do I do in what order this weekend?” — they list what must be true, not when to make it true. This page is the execution sequence. It walks one worked tenant — Three Rivers Insurance — through three DIDs, one SIP trunk, and one support queue, from Saturday 09:00 to a phone system that takes real callers on Monday morning.

​
How to use this page

Inventory before you build. Every walkthrough below writes new rows onto live objects; capture what exists first so Saturday 09:00 starts from a snapshot, not a guess:
  • GET /api/v1/numbers — the current DID estate and each number’s route.
  • GET /api/v1/voice/sip-trunks — trunks already authorized.
  • GET /api/v1/voice/queues — queues, agents, and SLA targets. The same dump doubles as the Saturday-11:00 baseline.
Checklists are preflight evidence; this page is the sequence. The PSTN checklist and the CCaaS runbook tell each owner what to prove and file; this page tells them when to run each check so the proofs land in dependency order. Sign-off rows on those two sheets reference the slot below — not the other way around. Owners. The worked tenant assigns three: Maya (Operations) owns numbers, queues, staffing, and the rollback call; Devon (Engineering) owns routing, trunks, and registration; Priya (Compliance) owns attestation, E911, and recording consent. Every slot below names its owner; an unnamed step is an unowned risk.

​
Prerequisites

Do not start Saturday without these — a missing one turns an execution weekend into a discovery weekend:
  1. The platform gates of the production go-live checklist pass: KYC approved, live API key active, wallet funded, webhooks verified.
  2. Inventory on the old system: every DID, its current route, and its carrier account number — you cannot wave-order what you have not listed.
  3. The three owners named and reachable for Saturday and Sunday.
  4. A roll-forward plan for Monday (see Sunday 16:00), approved by all three before the first LOA is signed.

​
The worked tenant

Three Rivers Insurance migrates off a premises PBX with: Wave order and the routing decision come from this table; the rest of the page treats it as the spec.

​
Saturday 09:00 — Number inventory and porting wave order

Owner: Maya (Operations). Time: 90 minutes. Ports are the only step in this plan whose lead time you do not control, so they go first.
  1. Collect the three accounts. For each DID, pull the carrier account number, the PIN, and the authorized signer from the losing carrier. Build the inventory against Port numbers.
  2. Sign three LOAs, one per DID. Every port needs a letter of agency from the account holder. Walk the paperwork end to end once with the first-port walkthrough so the second and third are copy-paste; POST /api/v1/numbers/porting submits each order against the same carrier account.
  3. Assign waves. The wave plan exists so a stuck FOC never strands the main number:
  4. Request FOC for Monday 06:00 on all three. Firm order commitments from the losing carrier land before the weekend closes; Monday 06:00 keeps the cutover off-peak and ahead of business hours.
  5. Record the windows. Each porting order exposes its FOC date and status timeline (GET /api/v1/numbers/porting/{id}/timeline). filled waves cleanly; a foc_rejected or a port that stalls in submitted bumps the affected DIDs to the next carrier window and flips the rollback names in the Sunday-16:00 worksheet. Batch cadence and status vocabulary follow porting sequence.
Exit test: three LOAs signed, three port orders submitted, FOC windows written down, and the carrier account/PIN document filed where Devon and Priya can reach it.

​
Saturday 11:00 — Routing decision

Owner: Devon (Engineering). Time: 2 hours. Pick how live calls reach the tenant now, because everything after lunch configures a different path.
  • SIP trunk (BYOC). Your own PBX keeps dialing out; inbound terminates at Orbit over a trunk you authorize. Choose it when a premises system survives the migration — Three Rivers keeps its conference-room PBX, so the trunk is the connecting leg. Guide: Connect a SIP trunk (BYOC).
  • API direct. No reuse hardware; the Devotel softswitch handles the trunk. Choose it when nothing from the old system is kept.
  • Host-associated DID. A DID rings a registered PBX or softphone extension. Choose it when you only need a direct line live, not a queue.
For Three Rivers (SIP trunk):
  1. Authorize the trunk (POST /api/v1/voice/sip-trunks): SSL on, the TLS endpoint IP and port set, digest credentials minted, and the PBX’s public egress IP allowlisted.
  2. Register both legs and place the loop. Register the conference-room PBX on the trunk leg and one browser softphone on the app leg per the browser softphone guide. The first-call walkthrough supplies the probe (/api/v1/voice/sip-trunks/probe) and the exact 200 OK INVITE/REGISTER checks.
  3. One registered softphone loop per leg. Place an outside-to-PBX call across the trunk and a softphone-to-softphone call on the app leg. Sprint rule: a leg that loops in one direction only is a misconfiguration, not a partial success — fix it before leaving the slot.
Exit test: the trunk row shows registered, each leg passed one full call loop, and the chosen path is written at the top of the sign-off worksheet so nobody re-litigates it on Sunday.

​
Saturday 14:00 — STIR/SHAKEN attestation and E911 drill

Owner: Priya (Compliance). Time: 90 minutes. Both drills run before any DID carries traffic, so a caller-ID or emergency-address defect is found on Saturday, not Monday.
  1. Set the attestation posture. Assemble the STIR/SHAKEN attestation guide end to end: resolve each DID to the ownership level it actually qualifies for (full A where the number is yours and the identity matches), set the attestation floor, and own the delegate-certificate lifecycle on any ported number the floor depends on.
  2. Verify on the wire. Read the attestation header off the live trace from the 11:00 test calls — full A, not B or C — and cross-check the attestation checklist tool, which reports the same level the carrier sees on each DID.
  3. Enable E911 drill mode. Point the emergency dial at the test destination per the E911 drill guide — a drill routes to the test desk, never a live PSAP.
  4. Dial 933 and read back the address. The drill returns the address-of-record for the customer’s physical service address. File the returned address in the compliance binder; if it reads stale or wrong, correct the address on file and re-drill — this gate blocks only its own exit test.
  5. File acceptance, then exit drill mode. The drill acceptance report (the dial-to-test-destination check, the address it returned, the timestamp) goes into the binder with the attestation snapshot. Live short emergency codes (911/112/999/000) remain blocked at platform dispatch — drill mode exercises the 933 path only.
Exit test: attestation renders as full A on a live outbound trace, the checklist tool reads green on all three DIDs, the 933 drill returned the filed address, and the acceptance report is in the binder.

​
Sunday 09:00 — Queue staffing

Owner: Maya (Operations). Time: 2 hours. Build the queue the main DID will terminate into:
  1. Create the support queue per Set up and run voice queues — concrete values, not defaults: maxWaitSeconds, targetServiceLevelSeconds, the overflowAction (voicemail box), the routingStrategy, and the skill tags a caller must match.
  2. Enroll the first agent and mint the softphone credential. Register one agent’s softphone end to end per the browser softphone guide and enroll the agent with the matching skill so the eligibility set is not empty. Enroll only where the skill matches — a queue that filters on a skill nobody holds answers no one. (The first-queue tutorial this slot pairs with is the voice-queues guide.)
  3. Wire wrap-up codes. Define the queue’s disposition catalog per wrap-up codes: at minimum resolved, callback-requested, wrong-department, and the code the Saturday-16:00 SIP fallback call used (trunk-fallback). Set requireDisposition on for launch week so every call carries an outcome.
  4. Point the main DID. Attach the queue route to +1 312 555 0164 (route type queue with the new queueId) — the port has not landed, so this is pre-positioning, not traffic.
  5. Place one real outside call. From a personal mobile, dial the toll-free number already moved (or the softphone’s test DID), reach the queue, and let the enrolled agent answer. This single call is the first outside caller the queue ever served — if it lands, wiring, eligibility, and the softphone registry are all proven at once against the live floor.
Exit test: one real outside call answered in the queue, one wrap-up code recorded, and the DID-to-queue row visible on GET /api/v1/numbers.

​
Sunday 13:00 — Recording, retention, and compliance flags

Owner: Priya (Compliance). Time: 90 minutes. Recording is a tenant-owned control: you decide whether calls record, for how long they live, and where the media lands.
  1. Turn the recording lifecycle on. Enable recording per recording lifecycle operations and set the retention window — Three Rivers records all three DIDs and keeps media 90 days, because its regulator requires a defined window rather than indefinite retention. Choose Orbit-managed storage unless the tenant owns the archive, and verify the lifecycle job enforces the window, not just records it.
  2. Wire BYO storage if the tenant owns the archive. If retention must land in the tenant’s own bucket, follow voice recording BYO storage and confirm a recorded call materializes an object in the tenant bucket — not just a green config row.
  3. Choose the consent prompt or beep per jurisdiction. Two-party consent jurisdictions take the per-queue consent prompt; one-party jurisdictions take the periodic beep. Set the flag per queue, then verify the prompt or beep actually fires on a live test call per the consent prompt configuration. The prompt is a tenant-owned control; the platform carries it, your jurisdiction chooses it.
  4. Verify on both call shapes. A recorded call produces a media object with the retention date set and the consent artifact in the CDR; a call you excluded from recording produces nothing. Both outcomes are proof — check each.
Exit test: retention window is set, a test call produced a media object with the consent artifact attached, and the lifecycle ran over the window correctly.

​
Sunday 16:00 — Rollback, sign-off, and the Monday plan

Owner: all three. Time: 60 minutes. Close the weekend with a rollback path you can execute, a worksheet you can sign, and a Monday you can run. Rollback. Every DID keeps its old route stored against it, so rollback is a re-pointable single write per DID:
  • Repoint +1 312 555 0164 back at the legacy destination by updating the number’s route (PATCH /api/v1/numbers/{id}) to the pre-migration value. The port never landed in-tenant, so the carrier simply keeps answering the old path.
  • The trunk disable is the second line: flip the trunk row inactive on PATCH /api/v1/voice/sip-trunks/{id} and the monitored alarms go quiet with the legs.
  • Fill the PSTN/CCaaS sign-off worksheet — every check on the PSTN checklist and the CCaaS runbook now has an owner, a result, and evidence in the binder. Those sheets remain the preflight record; this page was the order you ran them in.
Monday 06:00 — the FOC window opens. Confirm each port’s FOC at 06:00, re-point each landed DID to its new route, and watch; the hour-by-hour plan: The PSTN checklist and the CCaaS runbook hold the sheet format; this table is when to run each line of it.

​
Failure playbook — the three likeliest jams

  • FOC rejected on a wave. The losing carrier bounced the port (bad account number, mismatched signer, or a freeze on the line). The affected DID falls back to its wave’s rollback name; correct the rejection reason per porting sequence and resubmit for the next window. The main number never ports before wave 1 clears, so a wave-1 rejection delays the schedule, never strands it.
  • Trunk registration 401-loop before 15:00. The SIP credential on the trunk leg does not match what the PBX presents, or the egress IP is not allowlisted. Triage off the troubleshooting page (REGISTER/401/REGISTER-200OK triplet) and stay in drill mode — do not proceed to DID re-pointing until the Saturday-11:00 exit test passes again.
  • Consent prompt or beep silent on a live call. The per-queue consent flag is off, or the prompt asset failed to attach. Re-check the recording-consent configuration, place one more test call, and only then close the Sunday-13:00 slot. A missing consent artifact in a recorded call is a regulator finding, not a cosmetic defect.