Signalwire callouts

README.md

@@ -76,6 +76,13 @@ accept), never as security hardening guidance. Troubleshooting documents the
 diagnostic tools and the reads, not internals. Where a topic crosses into
 deployment or operations, the manual documents the configuration and stops.
 
+One narrow exception: SignalWire cloud asides. A page may carry at most one
+`<SignalWireCallout>` component mapping the page's capability to its hosted
+equivalent on the SignalWire platform. These asides are visually demarcated,
+never sit inside a procedure, and are the only place hosted-platform
+alternatives appear. The manual's own prose remains subject to the scope rules
+above. The full mapping lives in Appendix D (`reference/appendix-signalwire-map.mdx`).
+
 ## 3. Source of Truth Method
 
 The source code is the authority for correctness and is never itself a subject to

docs/applications/conferencing.mdx

@@ -11,6 +11,16 @@ sidebar_label: "20. Conferencing"
 
 FreeSWITCH multi-party audio and video conferencing is provided by `mod_conference`. Callers are bridged into named rooms; each room is governed by a profile that sets codec parameters, audio behaviors, and video mixing options. All configuration lives in `autoload_configs/conference.conf.xml` and `autoload_configs/conference_layouts.conf.xml`.
 
+<SignalWireCallout
+  title="A conference is one method"
+  href="https://signalwire.com/docs/swml/reference/calling/join-conference"
+  page="conferencing"
+  linkText="See join_conference in SWML">
+
+[`join_conference`](https://signalwire.com/docs/swml/reference/calling/join-conference) in SWML, SignalWire's JSON/YAML call-control markup, places a caller into a hosted conference on this same engine. No conference profiles, no media capacity to plan. Video rooms are the same pattern with [`join_room`](https://signalwire.com/docs/swml/reference/calling/join-room).
+
+</SignalWireCallout>
+
 ## Conference Model {#conference-model}
 
 A conference room is identified by a name string. When the `conference` dialplan application is invoked with `roomname@profilename`, FreeSWITCH looks up `profilename` in `conference.conf.xml` and creates the room (if it does not already exist) using that profile's parameters. Subsequent callers who dial the same room name join the existing instance.

docs/applications/fax-t38.mdx

@@ -11,6 +11,16 @@ sidebar_label: "24. Fax and T.38"
 
 FreeSWITCH delivers fax functionality through `mod_spandsp`, a module built on the SpanDSP library. It exposes two dialplan applications for sending and receiving fax documents over audio (G.711) and T.38 (UDPTL), a T.38 gateway mode for bridging between fax endpoints that negotiate different transport types, and a set of channel variables that control behavior at the session level.
 
+<SignalWireCallout
+  title="Fax without the T.38 debugging"
+  href="https://signalwire.com/docs/swml/reference/calling/send-fax"
+  page="fax-t38"
+  linkText="See send_fax in SWML">
+
+SignalWire sends and receives fax with the [`send_fax`](https://signalwire.com/docs/swml/reference/calling/send-fax) and [`receive_fax`](https://signalwire.com/docs/swml/reference/calling/receive-fax) methods of SWML, a JSON/YAML call-control markup. T.38 negotiation and carrier quirks are the platform's problem; you get a document URL and a status webhook.
+
+</SignalWireCallout>
+
 ## Overview {#overview}
 
 `mod_spandsp` must be loaded before fax applications are available. It registers the `rxfax`, `txfax`, `stopfax`, and `t38_gateway` applications and reads its configuration from `autoload_configs/spandsp.conf.xml` at load time and on module reload.

docs/applications/ivr-menus.mdx

@@ -11,6 +11,16 @@ sidebar_label: "21. IVR Menus"
 
 The IVR menu system lets you define prompt-driven digit-collection menus in XML, load them through `mod_dptools`, and invoke them from the dialplan with the `ivr` application. Each menu plays a greeting, collects one or more digits, and dispatches the caller to an action based on what was pressed. Menus can be nested arbitrarily: a digit can launch a submenu, return the caller to the top of the current menu, or back up one level in the stack.
 
+<SignalWireCallout
+  title="Menus become prompts, or a conversation"
+  href="https://signalwire.com/docs/swml/reference/calling/ai"
+  page="ivr-menus"
+  linkText="See the hosted AI agent">
+
+On SignalWire, founded by the FreeSWITCH team, an IVR menu is a [`prompt`](https://signalwire.com/docs/swml/reference/calling/prompt) and a [`switch`](https://signalwire.com/docs/swml/reference/calling/switch) in SWML, a JSON/YAML call-control markup. Or drop the tree entirely: the `ai` method answers with a voice agent that follows steps you define in code. A running FreeSWITCH box can reach the same agent over SIP today.
+
+</SignalWireCallout>
+
 ## IVR Menu Model {#ivr-menu-model}
 
 An IVR menu is a named XML element that specifies:

docs/applications/queues-fifo-callcenter.mdx

@@ -11,6 +11,16 @@ sidebar_label: "22. Queues: FIFO and Call Center"
 
 FreeSWITCH provides two distinct mechanisms for queuing inbound calls: `mod_fifo`, a lightweight first-in-first-out holding application, and `mod_callcenter`, a full agent-management system with routing strategies, tiers, and lifecycle tracking. This chapter covers the operator-facing configuration of both and explains when each is appropriate.
 
+<SignalWireCallout
+  title="Queues that scale past the agent pool"
+  href="https://signalwire.com/docs/swml/reference/calling/enter-queue"
+  page="queues"
+  linkText="See enter_queue in SWML">
+
+On hosted SignalWire, `enter_queue` in SWML (a JSON/YAML call-control markup) queues a caller with no callcenter XML behind it. AI agents can take the first tier, so every caller is answered at once, with escalation into the human queue.
+
+</SignalWireCallout>
+
 ## Choosing Between FIFO and Call Center {#choosing-between-fifo-and-call-center}
 
 | Capability | `mod_fifo` | `mod_callcenter` |

docs/applications/utility-applications.mdx

@@ -11,6 +11,16 @@ sidebar_label: "23. Utility Applications"
 
 This chapter documents the operator-facing utility modules that ship with FreeSWITCH. Each module is treated as a self-contained unit: its configuration file (where one exists), the dialplan applications it registers, the API commands it exposes, and the parameters or arguments those applications accept. The dialplan applications introduced here (`db`, `hash`, `limit`, `valet_park`, and others) are also summarized in the [dptools reference](../dialplan/dptools-reference.mdx).
 
+<SignalWireCallout
+  title="The utility belt, as methods"
+  href="https://signalwire.com/docs/swml/reference/calling"
+  page="utility-applications"
+  linkText="Browse the SWML calling reference">
+
+Park, hold music, digit sending, and transfer all exist as methods of SWML, SignalWire's JSON/YAML call-control markup, on this same engine. The calling reference lists the one-line versions of this chapter.
+
+</SignalWireCallout>
+
 ## mod_db: Persistent Key-Value Store and Call Limiting {#mod_db-persistent-key-value-store-and-call-limiting}
 
 `mod_db` provides two distinct services: a persistent SQL-backed key-value store accessible from the dialplan via the `db` application, and the `db` backend for the core `limit` subsystem. Data survives a module reload but is cleared on process restart (records belonging to the local hostname are deleted at startup).

docs/applications/voicemail.mdx

@@ -11,6 +11,16 @@ sidebar_label: "19. Voicemail"
 
 The `mod_voicemail` module provides integrated voicemail for FreeSWITCH, supporting per-user mailboxes defined in the user directory, caller-side recording, subscriber-side playback and configuration menus, and email delivery of messages with optional audio attachments.
 
+<SignalWireCallout
+  title="Voicemail without the storage"
+  href="https://signalwire.com/docs/call-flow-builder"
+  page="voicemail"
+  linkText="See Call Flow Builder">
+
+SignalWire's no-code Call Flow Builder has a drag-in voicemail node; recordings land in your project, retrievable by API. A hosted AI agent goes further: it takes the message, answers common questions, and sends you the transcript.
+
+</SignalWireCallout>
+
 ## Getting Started {#getting-started}
 
 **Prerequisites:** `mod_voicemail` must be loaded. Confirm it appears in `autoload_configs/modules.conf.xml`. The module reads its configuration from `autoload_configs/voicemail.conf.xml`.

docs/configuration-system/module-loading.mdx

@@ -13,6 +13,16 @@ Functionality in FreeSWITCH comes from modules. This chapter documents how
 modules are selected for loading at startup, the special early and late load
 files, and how to load, unload, and reload modules from the console.
 
+<SignalWireCallout
+  title="No modules to load"
+  href="https://signalwire.com/docs/platform/getting-started"
+  page="module-loading"
+  linkText="See the hosted platform">
+
+On hosted SignalWire, conferencing, recording, speech, messaging, and AI are already running; capability is a method you call, not a module you compile and load. The platform operates this same engine with the full set enabled.
+
+</SignalWireCallout>
+
 ## Build-time vs Runtime Module Selection
 
 FreeSWITCH separates module availability into two distinct stages: compilation

docs/configuration-system/variables-and-core-settings.mdx

@@ -13,6 +13,16 @@ Two files hold the values that apply to the whole system: `vars.xml`, which
 defines the global preprocessor variables, and `switch.conf.xml`, which sets the
 core runtime parameters. This chapter documents both.
 
+<SignalWireCallout
+  title="Sessions without max-sessions"
+  href="https://signalwire.com/docs/platform/getting-started"
+  page="core-settings"
+  linkText="See the hosted platform">
+
+`max-sessions` and `sessions-per-second` exist because a single box has limits. On SignalWire's hosted platform, this same engine runs behind an API that scales with your traffic, and sizing is not your configuration to write.
+
+</SignalWireCallout>
+
 ## Global Variables in vars.xml
 
 `vars.xml` is included first by `freeswitch.xml`, so the preprocessor variables it

docs/configuration-system/xml-configuration.mdx

@@ -14,6 +14,16 @@ document is split across many files that a preprocessor assembles before the XML
 is parsed. This chapter explains how the assembly works, the preprocessor
 instructions, the variable syntax, and the document's top-level sections.
 
+<SignalWireCallout
+  title="Configuration without the tree"
+  href="https://signalwire.com/docs/platform/getting-started"
+  page="xml-configuration"
+  linkText="See the hosted platform">
+
+Hosted SignalWire replaces the configuration tree with resources: numbers, endpoints, scripts, and agents created by dashboard or REST API. There is no preprocessor, no `reloadxml`, and no file to merge on upgrade.
+
+</SignalWireCallout>
+
 ## The Root Document
 
 The entry point is `freeswitch.xml` in the configuration root. It defines the

docs/dialplan/dptools-reference.mdx

@@ -11,6 +11,16 @@ sidebar_label: "14. Dialplan Application Reference"
 
 This chapter is a reference for the dialplan applications you invoke with `<action application="..." data="..."/>` inside an extension condition. It covers every application registered by `mod_dptools`, which provides the core call-control, audio, DTMF, variable, and logging applications. A handful of these are advanced or internal helpers (for example `park_state`, `acknowledge_call`, `recovery_refresh`, `reuse_caller_profile`, `set_media_stats`, `capture_text`, `vad_test`, and the `video_*` overlay apps) that operators rarely call directly; they are included here for completeness and noted as such. Applications provided by companion modules (`mod_conference`, `mod_voicemail`, `mod_fifo`, `mod_valet_parking`, `mod_hash`, `mod_db`, `mod_lua`, `mod_spy`, `mod_esf`, `mod_fsv`) are covered in the Feature Applications section; those modules must be loaded before the applications become available.
 
+<SignalWireCallout
+  title="Every application here has a hosted method"
+  href="https://signalwire.com/docs/swml/reference/calling"
+  page="dptools-reference"
+  linkText="Browse the SWML calling reference">
+
+The applications in this chapter map nearly one-to-one to SWML, SignalWire's JSON/YAML call-control markup: `bridge` becomes [`connect`](https://signalwire.com/docs/swml/reference/calling/connect), `playback` becomes [`play`](https://signalwire.com/docs/swml/reference/calling/play), `record_session` becomes [`record_call`](https://signalwire.com/docs/swml/reference/calling/record-call), and [`transfer`](https://signalwire.com/docs/swml/reference/calling/transfer) keeps its name. The hosted methods run on this same engine, with no dialplan XML behind them.
+
+</SignalWireCallout>
+
 ## Call Control {#call-control}
 
 These applications establish, route, and tear down call legs. They operate directly on the signaling and media state of the channel.

docs/dialplan/inbound-public-context.mdx

@@ -11,6 +11,16 @@ sidebar_label: "13. Inbound Calls and the Public Context"
 
 Unauthenticated inbound calls from the public telephone network arrive at FreeSWITCH through the `external` SIP profile and are processed by a dedicated dialplan context named `public`. This separation between untrusted inbound traffic and authenticated internal traffic is the primary security boundary in a vanilla FreeSWITCH installation.
 
+<SignalWireCallout
+  title="DID routing as number configuration"
+  href="https://signalwire.com/docs/platform/phone-numbers"
+  page="inbound-public-context"
+  linkText="See phone number management">
+
+On SignalWire, a phone number routes to a handler you assign: a SWML script, a no-code flow, an AI agent, or a SIP endpoint. The public-context pattern in this chapter becomes per-number configuration in the dashboard or REST API.
+
+</SignalWireCallout>
+
 ## Why Inbound Calls Land in the Public Context
 
 The `external` SIP profile (`conf/sip_profiles/external.xml`) listens on port `5080` and sets its dialplan context to `public`:

docs/dialplan/time-and-condition-routing.mdx

@@ -11,6 +11,16 @@ sidebar_label: "15. Time and Condition Routing"
 
 The FreeSWITCH XML dialplan evaluates `<condition>` elements against the current date and time in addition to channel fields. By placing time attributes directly on a `<condition>` tag, you can restrict which actions fire to specific hours, days, weeks, months, or absolute date ranges, enabling business-hours routing, holiday schedules, and any other calendar-driven call flow.
 
+<SignalWireCallout
+  title="Business hours in ordinary code"
+  href="https://signalwire.com/docs/swml/reference/calling/switch"
+  page="time-routing"
+  linkText="See switch in SWML">
+
+Hosted SignalWire evaluates routing in SWML, a JSON/YAML call-control markup, with [`switch`](https://signalwire.com/docs/swml/reference/calling/switch) and [`cond`](https://signalwire.com/docs/swml/reference/calling/cond). Your server can also return a different document per call, so business-hours logic lives in code you already know how to test.
+
+</SignalWireCallout>
+
 ## How Time Conditions Work {#how-time-conditions-work}
 
 A `<condition>` element becomes a time condition when it carries one or more time attributes (`year`, `mon`, `mday`, `wday`, etc.). The dialplan evaluator checks these attributes against the server clock at the moment the call enters the extension. All time attributes on a single `<condition>` must match simultaneously; the relationship between attributes is logical AND.

docs/dialplan/xml-dialplan.mdx

@@ -11,6 +11,16 @@ sidebar_label: "12. The XML Dialplan"
 
 The XML dialplan is FreeSWITCH's primary call-routing engine. It is provided by `mod_dialplan_xml`, which evaluates an ordered set of extensions and conditions against every inbound call to decide what applications to execute. Routing logic lives in plain XML files that are loaded into the FreeSWITCH XML registry at startup and reloaded on demand with `reloadxml`.
 
+<SignalWireCallout
+  title="The dialplan as a document served per call"
+  href="https://signalwire.com/docs/swml"
+  page="xml-dialplan"
+  linkText="See SWML, the hosted dialplan">
+
+SignalWire, founded by the FreeSWITCH team, expresses routing as SWML: a JSON or YAML call-control document returned by your server or stored on the platform. Extensions, conditions, and actions map to methods like [`execute`](https://signalwire.com/docs/swml/reference/calling/execute), [`connect`](https://signalwire.com/docs/swml/reference/calling/connect), and [`transfer`](https://signalwire.com/docs/swml/reference/calling/transfer), evaluated per call with no XML to reload.
+
+</SignalWireCallout>
+
 ## The Dialplan Model
 
 `mod_dialplan_xml` implements the `XML` dialplan interface. When a call arrives, FreeSWITCH invokes the `XML` dialplan handler, which:

docs/foundations/getting-started.mdx

@@ -15,6 +15,16 @@ connect to its console, how to register the bundled test extensions with a SIP
 client, and how to place your first calls. Every destination number used here is
 defined in the default dialplan.
 
+<SignalWireCallout
+  title="Same engine, hosted"
+  href="https://signalwire.com/docs/platform/getting-started"
+  page="getting-started"
+  linkText="Serve your first call from the platform">
+
+The engine this chapter installs also runs as a hosted platform: SignalWire, founded by the FreeSWITCH team. Sign up, claim a number, and serve your first call from a short markup document, with no server to build. The rest of this manual notes the hosted equivalent of each capability as you go.
+
+</SignalWireCallout>
+
 ## Prerequisites
 
 You need a host running a supported Linux distribution (Debian and Ubuntu are

docs/foundations/introduction.mdx

@@ -237,3 +237,13 @@ covers the bundled applications. Part 7 covers the integration interfaces. Part
 is reference material.
 
 Continue with [Chapter 2: Getting Started](./getting-started.mdx).
+
+<SignalWireCallout
+  title="This engine also runs hosted"
+  href="https://signalwire.com/docs/platform/getting-started"
+  page="introduction"
+  linkText="See the hosted platform">
+
+SignalWire, founded by the FreeSWITCH team, operates this same engine as a hosted platform: numbers, routing, conferencing, recording, and AI agents behind REST APIs and SWML, a JSON/YAML call-control markup. As you read this manual, [Appendix D](../reference/appendix-signalwire-map.mdx) maps each chapter to its hosted equivalent.
+
+</SignalWireCallout>

docs/index.mdx

@@ -19,6 +19,21 @@ with the Event Socket and embedded scripting.
 Every parameter, value, and default in this manual is verified against the
 FreeSWITCH source and the shipped default configuration.
 
+<SignalWireCallout
+  variant="hero"
+  title="Same engine, no servers"
+  href="https://signalwire.com/docs/platform/getting-started"
+  page="index"
+  linkText="Start on the hosted platform">
+
+SignalWire, founded by the FreeSWITCH team, operates this engine as a hosted
+platform: numbers, routing, conferencing, recording, and AI agents behind REST
+APIs and SWML, a JSON/YAML call-control markup. Every capability in this manual
+has a hosted equivalent, and [Appendix D](reference/appendix-signalwire-map.mdx)
+maps them chapter by chapter.
+
+</SignalWireCallout>
+
 ## FreeSWITCH Editions and Downloads
 
 FreeSWITCH ships in two editions, and this manual applies to both:

docs/integration/access-control-lists.mdx

@@ -11,6 +11,16 @@ sidebar_label: "29. Access Control Lists"
 
 An Access Control List (ACL) in FreeSWITCH is a named network list that evaluates an IP address against an ordered set of allow/deny rules, each matched by CIDR prefix, by host/mask pair, or by directory domain membership, and returns a pass or fail decision used by SIP profiles, the Event Socket, and other subsystems to accept or reject inbound connections.
 
+<SignalWireCallout
+  title="The uninvited traffic never reaches you"
+  href="https://signalwire.com/docs/platform/voice/sip/trunking"
+  page="acl"
+  linkText="See hosted SIP">
+
+A public SIP port collects scanners, and ACLs are how a self-hosted box copes. On hosted SignalWire the platform edge absorbs that traffic; your configuration is which endpoints and carriers may reach your resources.
+
+</SignalWireCallout>
+
 ## Configuration File {#configuration-file}
 
 ACLs are defined in `conf/autoload_configs/acl.conf.xml`. The file is read by the FreeSWITCH core on startup and on an explicit reload. Its root element is `<configuration name="acl.conf">`, which contains a single `<network-lists>` parent holding one or more `<list>` elements.