docs(sip): state that SIP presence and PIDF-LO are not supported

[Devon-White]

Summary

Resolves signalwire/cloud-product#20822: no docs page mentioned PIDF-LO or SIP presence, so the Sigmond assistant answered the support query "PIDF-lo support SIP presence" from the unrelated Bring your own carrier page.

Investigation (ticket comment) found no customer-facing usage of either feature on the cloud platform, so this documents them as not supported.

Changes

fern/products/platform/pages/calling/voice/SIP/index.mdx

• New ## Presence and location support section: explains SIP presence (SUBSCRIBE/NOTIFY, PIDF, BLF) and PIDF-LO (RFC 4119/5491, Geolocation header), states both are unsupported, points to the E911 guide as how location reaches the dispatcher, and closes with a support contact line.
• One-sentence pointer after the generic "Presence information" feature list linking to the new section.

Sourcing

• SIP presence: every cloud FreeSWITCH SIP profile sets manage-presence=false.
• PIDF-LO: no handling in prime-rails; #6975 closed as not needed; E911 is registered-address provisioning only.
• Dashboard registration visibility / no API: cloud-product#20669.
• Open caveat: Kamailio edge config wasn't readable. If the edge answers presence SUBSCRIBEs independently, the presence paragraph needs revising.

Verification

• yarn fern-md-check passes (2823 files).
• Preview: /docs/platform/voice/sip, confirm the #presence-and-location-support anchor resolves.
• After merge: rebuild the Sigmond corpus and confirm "PIDF-lo support SIP presence" retrieves this page.

🤖 Generated with Claude Code

[github-actions]

🌿 Preview

https://signalwire-preview-docs-662.docs.buildwithfern.com/docs

---

View workflow run

[hey-august]

Fix before merge

• "The Dashboard shows whether a SIP Credential is currently registered" is inaccurate. The Dashboard lists a "Last Registered" timestamp for each credential, not a live registered/unregistered state. Rewrite to "The Dashboard shows when a SIP Credential last registered". The rest of the sentence holds: neither REST spec exposes a registration field and no webhook covers it.

Grounding notes

• Presence not supported is confirmed. The SIP profiles devices register against have presence handling disabled.
• PIDF-LO not read or added rests on absence of evidence. No handling of the Geolocation header or PIDF bodies exists in the call-routing or SIP configuration I checked. That is consistent with the claim, but worth a one-line confirmation from Voice engineering before publishing an E911 statement.
• The heading anchor #presence-and-location-support follows the auto-slug pattern used elsewhere, for example the prompt-engineering guide. No check covers anchors, so preview once.

Should fix, small

• The "Flexibility" list still promises what the new section denies. Lines 60 to 64 say SIP gives you "the capability to identify a user's location", "determine user availability", and "user presence information, and E911 calls". The new pointer sentence only covers the Overview list. Either extend the pointer to this list or add "of the protocol" framing there too, so a reader who skims to Benefits doesn't leave with the wrong answer.
• Bold-lead paragraphs. The two definition paragraphs open with **SIP presence** and **PIDF-LO** as labels. The style rule bans bold labels as a paragraph substitute. Plain openers read fine: "SIP presence is the SUBSCRIBE/NOTIFY event package…".
• "so the request is on record" is an odd close for a customer. "so the request is tracked", or simply "to request either capability, contact SignalWire support", is cleaner.

Fine as is

• RFC 4119 and RFC 5491 are the right citations. E911 link matches the target page's slug. Terminology matches the page and the REST spec ("SIP Credential"). Support link form matches sibling pages. Placement between Benefits and softphone setup is sensible, and the section is the kind of retriever target the ticket asked for. MDX check passes on all files.