Webex Calling Third-Party Devices: Paging, ATAs, Fax, and Modems

Direct answer: inventory every odd device before moving a user

A CUCM to Webex Calling migration is not only about desk phones. Paging systems, door phones, elevator phones, alarm panels, fax machines, analogue handsets, and other devices may be hiding behind an ATA or voice gateway.

Record the exact device, port type, number, call path, business owner, and test procedure. Then confirm that Webex Calling, the selected gateway, the PSTN provider, and every application in the path support it. A label saying “analogue” is not a design.

The same rule applies to recording. If a specialist endpoint makes a business call that must be retained, test whether the new call path reaches [call-recording.com](/). An endpoint appearing in Control Hub does not prove that its media is available to a recording source.

Find the devices nobody put on the project plan

Start with CUCM devices and route-plan reports, but do not stop there. Walk the sites and speak to facilities, security, operations, and compliance teams. Look for:

• elevator and refuge phones;
• alarm and building-management diallers;
• reception and warehouse paging adapters;
• door entry and intercom devices;
• fax machines and multifunction printers;
• analogue conference phones;
• modems and telemetry equipment;
• credit-card or point-of-sale terminals; and
• third-party SIP phones registered to CUCM.

For each one, find somebody who can demonstrate what “working” means. An elevator phone that can receive a test call is not necessarily able to place its required emergency call.

Separate ATA, voice gateway, SIP device, and PSTN line

An analogue telephone adapter converts one or more analogue ports into IP voice. Cisco currently lists the ATA 191 and ATA 192 Multiplatform models for Webex Calling. Larger Cisco VG400, VG410, and VG420 gateways can serve multiple analogue phones, fax machines, modems, and paging systems, subject to the actual Webex Calling support restrictions.

A third-party SIP device is different. It may register directly to Webex Calling using credentials, but Cisco describes these as customer-managed devices with basic SIP calling rather than full Cisco phone feature support.

A direct carrier line is different again. For a life-safety or specialist device, retaining a suitable PSTN service can sometimes be safer than forcing it through a cloud migration merely to make the spreadsheet green.

Treat elevator and alarm phones as life-safety systems

Do not migrate an elevator, refuge, or alarm endpoint on the strength of a normal two-way call. Confirm power during an outage, emergency-number routing, location delivery, DTMF, supervision, line seizure, answer behaviour, callback, carrier support, and the maintenance provider's approval.

Some equipment expects electrical behaviour that an ATA does not reproduce. Some has been certified only with a particular line type. Get the lift, alarm, or building-system vendor involved and keep written acceptance evidence.

If calls from these devices are in recording scope, document why, where consent or notification is handled, and how they appear in the call-recording.com recording and message timeline. Life-safety engineering comes first; recording must not interfere with the primary function.

Test faxing from end to end

Fax can work through supported Webex Calling analogue gateways, but it is sensitive to packet loss, timing, codec changes, carrier conversion, and error correction. T.38 support on one box does not guarantee that every provider and gateway in the route uses it correctly.

Test the actual machines and actual destinations. Send short and long documents in both directions. Test busy, no-answer, retransmission, caller identification, and reports. If fax is legally or operationally important, test after every meaningful carrier, gateway, or network change.

Avoid promising that buying a better ATA will cure every fax issue. The end-to-end route matters more than the logo on the little box with two flashing lights.

Modems are the awkward answer nobody wants

Cisco's current supported-device guidance says modems are not supported in Webex Calling. That is a much stronger statement than “choose the right analogue converter.”

If the inventory finds modems, telemetry diallers, or data-over-voice applications, stop and redesign that service. Replace it with IP or cellular connectivity, retain a vendor-approved line outside Webex Calling, or obtain a specifically supported alternative from the equipment provider. Do not use a production cutover to discover that a 1998 modem has strong opinions about jitter.

Plan paging as an application, not just a handset

Paging might be a single analogue amplifier, a SIP paging adapter, a multicast application, or a multi-zone emergency-notification platform. Document zones, priorities, scheduled announcements, talkback, external triggers, emergency overrides, and whether phones participate as speakers.

Cisco voice gateways can connect supported analogue paging equipment. A supported third-party SIP paging device may also register to Webex Calling. Neither choice automatically recreates CUCM paging integrations or multicast behaviour.

Call recording may capture a call into the paging platform, the individual user's call, both, or neither, depending on the design. Put a real paging call through the proposed route and confirm the expected evidence arrives in call-recording.com, with the correct parties and timestamps.

Understand third-party SIP device limitations

Cisco-managed third-party devices use standard SIP and provide basic calling. Cisco's current guidance says their deployment is manual: they do not use activation codes, EDOS, or MPP onboarding, and they are added individually rather than in bulk.

Do not assume a third-party phone will gain Cisco shared-line behaviour, programmable keys, corporate directory features, firmware management, or troubleshooting telemetry. Check the device's Webex Calling support entry, required firmware, TLS and certificate handling, codecs, DTMF, emergency calling, and vendor support.

For hundreds of devices, “add individually” is not a tiny footnote. It is a staffing and scheduling problem wearing a SIP hat.

Map the recording path for every specialist endpoint

Draw the real media path. A device might register directly to Webex Calling, sit behind an ATA, reach CUCM through SIP, or use a local carrier via CUBE Local Gateway. Each path can have a different recording method and different metadata.

[call-recording.com](/) supports recording across suitable Cisco CUCM and Webex Calling environments, allowing recordings from migration waves to remain available through one dashboard. But support for the platform does not make every analogue gadget automatically recordable. Confirm the endpoint, calling feature, media route, and recording source together.

Test inbound and outbound calls, transfers, holds, conference calls, redirects, failover, and emergency exclusions. Search for each completed test in the dashboard and check audio, direction, parties, time, duration, and retention assignment.

Keep CUBE or CUCM when a dependency needs time

A Local Gateway can preserve PSTN routing and CUCM coexistence while specialist devices are replaced or validated. That is a legitimate migration phase, not a failure to be “cloud enough.”

Give every retained dependency an owner, reason, target state, cost, and review date. Otherwise the temporary CUBE becomes a permanent museum exhibit with an IOS XE maintenance contract.

Use the Webex Calling PSTN strategy guide to decide whether these services stay behind CUBE, use a Webex-supported gateway, or remain on a separate carrier service.

Run an acceptance test somebody can sign

For every device, record:

• source and destination numbers;
• inbound, outbound, and callback results;
• DTMF, audio, fax, page, or alarm behaviour;
• power and network-failure behaviour;
• emergency calling result where relevant;
• support confirmation and firmware version;
• recording result where required; and
• the named business and technical approvers.

Do not close the task because Control Hub shows a green dot. Close it when the real service works and its owner agrees.

Continue the CUCM to Webex migration series

Return to the complete CUCM to Webex Calling migration guide, or continue with Cisco phone and Jabber migration to Webex Calling.