resolving-spam-labels: cover call blocking (not just labeling), add SIP-code diagnosis, fix register-vs-dispute paths

[briankwest]

Summary

/platform/voice/resolving-spam-labels is solid on labeling (CNAM + attestation, Free Caller Registry, per-provider submissions, best practices, template). It does not cover blocking, and it is missing a diagnosis step that we are uniquely positioned to provide.

This came out of a support case where a customer's outbound calls to one destination failed after ~1s with a SIP 603 carrying an analytics reason header. Nothing was ever displayed on a handset, so "spam label" never described their problem — they filed under "outgoing calls not working." The guide had the right remediation but the customer would never have found it.

1. Scope gap: blocking vs. labeling

These are different failure modes and the guide only addresses one:

	Labeling	Blocking
Call completes	Yes	No
Symptom	Answer rate collapses	Calls fail in ~1s, no ring
Visible in SIP signaling	No — clean 200 OK	Yes — 603/607/608
How customers describe it	"we're flagged as spam"	"we can't call this number"

Suggest broadening the title/intro to cover both, so blocked customers land here. Search terms they actually use are about failing calls, not labels.

2. Add a diagnosis section keyed on SIP response codes

This is the highest-value addition and the one thing we can offer that a generic industry guide cannot, because customers can get their traces from us.

• 603 + Reason: SIP;cause=603;text="v=analytics1;url=...;id=..." — analytics block. The redress URL is embedded in the rejection itself.
• 607 Unwanted (RFC 8197) — recipient-reported
• 608 Rejected (RFC 8688) — rejected by an intermediary; designed to carry redress contact info in a Call-Info jCard
• 403 / 404 — not analytics; look elsewhere

Gotcha worth an explicit callout: the AT&T redress URL is https://www.att.com/redressC. The trailing capital C is part of the URL, not a typo. Plain att.com/redress is dead. It reads like a transcription error and gets silently "corrected" — this happened on the ticket above and we had to send the customer a correction email.

3. Label text is diagnostic — new mapping table

Verified today on Verizon's own form: Verizon uses the label "SPAM?" specifically, and states that other labels such as "Spam Likely" indicate a different provider's system. So the exact string the customer photographs tells you who to contact. That is a fast self-routing step we currently don't offer.

Pair it with a carrier→provider table, since customers report "Verizon flags us," never "TNS flags us":

Carrier	Analytics provider
AT&T	Hiya
T-Mobile	First Orion
Verizon	TNS

4. Separate "register" from "dispute" — verified, and it changes a link

These are different workflows with different URLs, and the guide currently blends them. Verified today:

• First Orion free number registration (firstorion.com/products/free-number-registration/) is proactive registration only — it has no dispute/appeal path for an existing label. Also worth noting: their free API access supports T-Mobile registrations only. Sending a customer here to fix an active mislabel is a dead end.
• reportarobocall.com (TNS) — the guide's existing link is correct and should stay. It does carry a business dispute path (up to 20 numbers with display names), alongside the consumer reporting path.
• voicespamfeedback.com/vsf/ is operated by Verizon directly, not TNS, and covers Verizon numbers only. It complements the TNS link rather than replacing it. Verizon explicitly warns that "your submission may not result in a change to how future calls are labeled" — worth quoting so we don't over-promise.

5. Free Caller Registry eligibility gate

Verified on the FCR site today: registration is restricted to businesses calling on their own behalf — explicitly not service providers, BPOs, or third parties registering numbers for another business.

Given how much of our base is ISVs and platforms dialing for end customers, a large share of readers will bounce off the step we currently recommend first. This needs a warning plus a "if this is you, go here instead" branch to the provider-direct routes.

6. Smaller additions

• Verification loop. Nothing tells customers how to confirm remediation worked. Labels are invisible from our side — it takes a handset on each carrier network or a paid monitoring service. Without this they cannot close the loop and they open a second ticket.
• Why redress doesn't stick. The best-practices list exists but isn't connected causally: redress clears the current block, it does not change scoring. If the calling pattern still scores as spam it returns within weeks. Making that link explicit is what turns the best-practices section from boilerplate into the actual fix.
• What SignalWire can and cannot do. We can pull traces, confirm blocking with evidence, and escalate reputation upstream. We cannot compel a carrier to unblock. Stating this sets expectations and reduces misdirected tickets.
• FCC redress rights. Terminating providers must maintain a single point of contact for blocking disputes and resolve erroneous blocking without charge and without undue delay. Rarely needed, real leverage when a provider stonewalls. (Not independently verified — confirm current rule text before publishing.)

Open items needing human verification

Two URLs returned HTTP 403 to automated fetching (Zendesk bot protection), so I could not confirm them. Both should be opened in a browser before publishing:

• https://hiyahelp.zendesk.com/hc/en-us/p/request_hub — currently in the guide as the Hiya path
• https://support.firstorionenterprise.com/hc/en-us/requests/new — candidate First Orion dispute path, to sit alongside their registration link
• Confirm FCC blocking-redress rule text before citing it

Proposed task list

• Broaden scope + title to cover blocking as well as labeling
• Add SIP response-code diagnosis section, incl. redressC callout
• Add label-text → provider and carrier → provider mapping tables
• Split register vs. dispute; add First Orion dispute path; keep reportarobocall.com; add Verizon-direct form with its caveat
• Add FCR eligibility warning + branch for service providers / third-party callers
• Add verification-loop, expectations, and "what SignalWire can do" sections
• Verify the three open items above

---

Verified-today items are marked as such. Everything else is a proposal, not a confirmed fact — please don't propagate the unverified claims into published copy without checking.