<\/span><\/h2>\nCisco Proximity relies on a dual-medium communication workflow. It pairs devices by using physical room acoustics to confirm physical presence, followed by an immediate handoff to standard IP networking for high-bandwidth data transmission.<\/p>\n
+-------------------------------------------------------------------+\n| PHYSICAL PRESENCE |\n| |\n| +--------------------+ +--------------------+ |\n| | Cisco Video Codec | | Client Device | |\n| | (Room Kit \/ Board) | | (Laptop \/ Phone) | |\n| +---------+----------+ +---------+----------+ |\n| | | |\n| | 1. Emits Ultrasonic Audio Beacon | |\n| | (20 kHz - 22 kHz, 180s Token) | |\n| |=======================================>| |\n| | | |\n| | [Decodes Token & Codec IPv4] | |\n+------------|----------------------------------------|-------------+\n | |\n+------------|----------------------------------------|-------------+\n | ENTERPRISE NETWORK | |\n | | |\n | 2. TCP 443 (HTTPS) Handshake & Auth | |\n |<---------------------------------------| |\n | | |\n | 3. Encrypted Data Session Established | |\n |<======================================>| |\n | - Wireless Screen Sharing | |\n | - Call Control \/ Snapshots | |\n+-------------------------------------------------------------------+\n<\/code><\/pre>\n<\/span>Phase 1: High-Frequency Acoustic Beacon Emission<\/span><\/h3>\nWhen Proximity is active, the Cisco video endpoint (such as a Cisco Room Kit, Board, or Desk series) continuously transmits an inaudible acoustic token through its integrated loudspeakers.
\n– Frequency Spectrum<\/strong>: The signal operates within the ultrasound audio spectrum, specifically between 20 kHz and 22 kHz<\/strong>. Because this range is near or beyond the upper limit of adult human hearing, it remains virtually silent to room participants while remaining detectable by standard consumer microphones.
\n– Payload Contents<\/strong>: The beacon does not transmit raw meeting data. Instead, it broadcasts a modulated acoustic payload consisting of the video system\u2019s endpoint identity, reachable IPv4 address, and an encrypted pairing token.
\n– Security Lifetime<\/strong>: To prevent session spoofing and replay attacks, the ephemeral acoustic token is regenerated dynamically every 180 seconds<\/strong>.<\/p>\n<\/span>Phase 2: Client Acoustic Capture and Demodulation<\/span><\/h3>\nThe client device (running the Webex App or legacy Cisco Proximity client) uses its active microphone to monitor ambient sound.
\n– The client software samples input audio\u2014typically requiring an audio subsystem configured at a 44.1 kHz or 48 kHz sampling rate<\/strong> to adhere to the Nyquist theorem for capturing signals up to 22 kHz.
\n– Digital signal processing (DSP) algorithms filter out low-frequency human speech, room reverberation, and background ambient noise, isolating the 20\u201322 kHz band.
\n– Once the signal is isolated, the app demodulates the token, retrieving the endpoint’s pairing parameters and target network address.<\/p>\n<\/span>Phase 3: Transition to Enterprise IP Handshake<\/span><\/h3>\nBecause sound waves cannot carry high-bandwidth video or handle bidirectional control requests, physical presence verification is solely a gating mechanism.
\n– As soon as the client application decodes the token, it immediately shifts the communication channel from acoustic audio to the enterprise Wi-Fi\/LAN network.
\n– The client initiates an outbound connection over TCP port 443 (HTTPS)<\/strong> directly to the endpoint\u2019s IPv4 address.
\n– During this TLS-encrypted handshake, the client presents the decrypted acoustic token back to the video system. The endpoint validates that the presented token matches its currently active 180-second broadcast cycle, confirming that the client is physically inside the meeting space and within earshot of the speakers.<\/p>\n<\/span>Phase 4: Bi-Directional Control and Content Session Activation<\/span><\/h3>\nUpon successful validation of the acoustic token over HTTPS, an authenticated session is established:
\n– Presentation Ingress<\/strong>: For wireless content sharing, the client establishes a desktop transmission stream using optimized H.264 video compression over local IP or WebRTC channels directly to the codec.
\n– Call Control & Feedback<\/strong>: The client receives session telemetry, allowing the user to view participant lists, adjust codec audio volume, dial directory contacts, or view incoming presentation slides directly on their personal screen.
\n– Session Termination<\/strong>: If the user leaves the conference room with their laptop or closes the door behind them, the device stops receiving the refreshed 180-second ultrasound token. When the current token expires without renewal, the endpoint closes the HTTPS session, disconnecting screen sharing to prevent data leakage outside the room.<\/p>\n
\n<\/span>Enterprise Network Requirements: Subnets, Ports, and Protocols<\/span><\/h2>\nWhile physical proximity is established through acoustic sound waves, data transmission and call management rely entirely on the IP network infrastructure. Enterprises must configure their network routing, firewall policies, and subnets to allow uninterrupted communication between client devices and video endpoints.<\/p>\n
<\/span>IP Routing and Addressing Constraints<\/span><\/h3>\n\n- Direct IPv4 Reachability<\/strong>: The Cisco Proximity pairing payload advertises the endpoint’s IPv4 address. The client\u2019s Wi-Fi network must have an active IP route to the video system’s subnet.<\/li>\n
- Absence of Hostname\/FQDN in Ultrasound<\/strong>: The acoustic beacon contains raw IP address structures; it does not broadcast fully qualified domain names (FQDNs) or hostnames.<\/li>\n
- IPv6 Limitations<\/strong>: Native end-to-end IPv6 pairing is not supported via the ultrasound token exchange. While clients may operate in dual-stack environments, the target endpoint must have an addressable IPv4 interface reachable by the client.<\/li>\n
- Network Address Translation (NAT) Restrictions<\/strong>: Client devices can reside behind a client-side NAT or Wi-Fi gateway provided they can initiate outbound connections to the codec\u2019s IPv4 address. However, placing the video endpoint behind a 1:many NAT boundary will break Proximity pairing, as the internal IP advertised in the ultrasound token will not match an address reachable from external client subnets.<\/li>\n<\/ul>\n
<\/span>Firewall Port Matrix<\/span><\/h3>\n\n\n\n| Protocol<\/th>\n | Destination Port<\/th>\n | Direction<\/th>\n | Source<\/th>\n | Destination<\/th>\n | Purpose<\/th>\n<\/tr>\n<\/thead>\n |
\n\nTCP<\/strong><\/td>\n443<\/strong><\/td>\n| Outbound<\/td>\n | Client (Laptop\/Mobile)<\/td>\n | Video Endpoint IP<\/td>\n | HTTPS API, token validation, call control, slide snapshots<\/td>\n<\/tr>\n | \nTCP<\/strong><\/td>\n80<\/strong><\/td>\n| Outbound (Optional)<\/td>\n | Client (Laptop\/Mobile)<\/td>\n | Video Endpoint IP<\/td>\n | HTTP-to-HTTPS redirect (if non-secure fallback is not disabled)<\/td>\n<\/tr>\n | \nUDP<\/strong><\/td>\nDynamic RTP Ranges<\/strong> (e.g., 52050\u201352299 or 5004)<\/em><\/td>\n| Bidirectional<\/td>\n | Client (Laptop\/Mobile)<\/td>\n | Video Endpoint IP<\/td>\n | Local presentation streaming (H.264 content share payload)<\/td>\n<\/tr>\n | \nTCP<\/strong><\/td>\n443 \/ 8443<\/strong><\/td>\n| Outbound<\/td>\n | Client & Video Endpoint<\/td>\n | Webex Cloud (*.webex.com<\/code>)<\/td>\n| Cloud-signaled pairing (when using Webex App and Cloud Proximity)<\/td>\n<\/tr>\n | \nUDP<\/strong><\/td>\n5004 \/ 9000<\/strong><\/td>\n| Outbound<\/td>\n | Client & Video Endpoint<\/td>\n | Webex Cloud Media Nodes<\/td>\n | Interactive media delivery when routing via hybrid cloud relays<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n<\/span>Administrative Configuration Guide: Enabling Proximity on Cisco Video Endpoints<\/span><\/h2>\nProximity services can be provisioned through the Cisco RoomOS web interface or programmatically via the command-line interface (xAPI \/ SSH). Follow these steps to activate the ultrasound beacon, set up content sharing permissions, and tune the pairing volume.<\/p>\n <\/span>Step 1: Access the Endpoint Management Interface<\/span><\/h3>\nLog into the endpoint\u2019s administrative console using a web browser (https:\/\/<codec-ip><\/code>) or establish an SSH session using administrative credentials:<\/p>\nssh admin@<codec-ip>\n<\/code><\/pre>\n<\/span>Step 2: Enable the Global Proximity Engine<\/span><\/h3>\nBefore individual services (such as screen sharing or call control) can operate, you must enable the core Proximity engine.<\/p>\n Via CLI (xAPI):<\/strong><\/p>\n# For on-premises registered endpoints (CUCM \/ VCS \/ Expressway)\nxConfiguration Proximity Mode: On\n\n# For Webex Cloud-registered or Webex Edge-linked endpoints\nxConfiguration Webex Proximity Mode: On\n<\/code><\/pre>\nVia Web Interface:<\/strong>
\n1. Navigate to Setup<\/strong> (or Settings<\/strong>) > Configuration<\/strong>.
\n2. Expand the Proximity<\/strong> section.
\n3. Locate Mode<\/strong> and set the toggle to On<\/strong>.
\n4. (If cloud-registered) Locate Webex<\/strong> > Proximity<\/strong> > Mode<\/strong> and set it to On<\/strong>.<\/p>\n<\/span>Step 3: Configure Permitted Proximity Services<\/span><\/h3>\nGranular controls allow administrators to decide whether users can push presentation content to the screen, receive presentation slides on their personal devices, or control call state.<\/p>\n Via CLI (xAPI):<\/strong><\/p>\n# Allow users to share content wirelessly from laptops\/mobiles to the room display\nxConfiguration Proximity Services ContentShare FromClients: Enabled\n\n# Allow client devices to view\/save presentation slides shared in the room\nxConfiguration Proximity Services ContentShare ToClients: Enabled\n\n# Allow paired mobile devices to answer, place, mute, or end video calls\nxConfiguration Proximity Services CallControl: Enabled\n<\/code><\/pre>\n<\/span>Step 4: Calibrate the Ultrasound Acoustic Volume<\/span><\/h3>\nThe ultrasound signal must be loud enough to cover the room without leaking into neighboring spaces or causing acoustic distortions. RoomOS provides both dynamic and static volume configuration modes.<\/p>\n # Option A: Dynamic volume (Recommended)\n# Automatically adjusts ultrasound volume based on room noise and microphone feedback\nxConfiguration Proximity Pairing Audio Volume Mode: Dynamic\n\n# Option B: Static maximum volume capping (Values typically range from 0 to 90; default is 70)\n# Lower this value in smaller huddle spaces to eliminate audio spill into adjacent rooms\nxConfiguration Audio Ultrasound MaxVolume: 65\n<\/code><\/pre>\n<\/span>Step 5: Verify Active Operational State<\/span><\/h3>\nCheck whether Proximity services are broadcasting correctly:<\/p>\n xStatus Proximity\nxStatus Proximity Services Availability\n<\/code><\/pre>\nExpected Output:<\/em><\/p>\n*s Proximity Mode: On\n*s Proximity Services Availability: Available\n*s Proximity PairingCount: 0\n** end\n<\/code><\/pre>\n
\n<\/span>Troubleshooting Common Pairing and Ultrasound Failure Modes<\/span><\/h2>\n<\/span>Why does the Webex or Proximity app stay stuck on “Searching for devices”?<\/span><\/h3>\nThis indicates that the client device is not picking up or decoding the 20\u201322 kHz acoustic beacon. Common causes include:
\n– Physical Barriers<\/strong>: If the laptop is placed behind a solid partition or inside a bag, ultrasound waves will be blocked.
\n– Closed Laptop Lid<\/strong>: Many enterprise users run their laptops closed while connected to external monitors. Closing the clamshell covers the internal microphone array, preventing ultrasound capture.
\n– Third-Party Sound Bars<\/strong>: If the Cisco codec output is routed through a third-party amplifier, TV speaker, or external soundbar that cuts off audio above 18 kHz, the ultrasound token will not be broadcast into the room. Use the codec’s certified internal speakers or full-range high-frequency drivers.<\/p>\n<\/span>How do operating system microphone permissions and sample rates disrupt pairing?<\/span><\/h3>\n\n- OS Privacy Permissions<\/strong>: Both modern macOS and Windows require applications to have explicit permission to access the microphone. If mic access is blocked for Webex, the app cannot capture the acoustic token.<\/li>\n
- Incompatible Sample Rates<\/strong>: Ultrasound detection requires an audio sampling rate of at least 44.1 kHz or 48 kHz. If a USB headset, external microphone, or sound driver defaults to a low-bandwidth telephony mode (such as 16 kHz or 8 kHz), the client cannot capture the 20\u201322 kHz spectrum.<\/li>\n
- Exclusive-Mode Audio Locks<\/strong>: If another application (such as an audio editor or recording tool) takes exclusive hardware control of the microphone (
AUDCLNT_E_EXCLUSIVE_MODE_NOT_ALLOWED<\/code>), the client will fail to listen.<\/li>\n- Aggressive Driver DSP<\/strong>: Certain laptop OEM sound enhancement utilities (e.g., Realtek Waves MaxxAudio, Lenovo Vantage Audio) treat high-frequency audio as unwanted hiss and aggressively filter out signals above 18 kHz. Disable external “Noise Suppression” or “Acoustic Smoothing” in the OS audio driver properties to resolve this.<\/li>\n<\/ul>\n
<\/span>Why does the device pair successfully, but fail when attempting to share content?<\/span><\/h3>\nIf the app shows “Connected to [Room Name]” but displays an error when clicking Share Screen<\/strong>, the ultrasound pairing handshake was successful, but the network-layer data transfer failed:
\n– Firewall Filtering on Port 443<\/strong>: The client and endpoint are often placed on separate network segments (e.g., an untrusted Guest\/Corporate Wi-Fi VLAN vs. an internal Video\/Voice VLAN). If inter-VLAN routing blocks outbound TCP port 443 towards the video endpoint IP, the client cannot transmit content or manage calls.
\n– NAT Traversal Failure<\/strong>: If a firewall between the Wi-Fi and video subnets performs bidirectional Network Address Translation, the direct IP connection will fail.
\n– Service Disabled in Endpoint Settings<\/strong>: Ensure that xConfiguration Proximity Services ContentShare FromClients<\/code> is explicitly set to Enabled<\/code> as detailed in the administrative guide above.<\/p>\n<\/span>Can ultrasound signals bleed through glass or conference room walls?<\/span><\/h3>\n\n- Audio Leakage<\/strong>: Ultrasound does not easily penetrate standard drywall, double-paned glass, or solid wood doors. However, it will escape through gaps under doors, HVAC transfer ducts, or open entrances.<\/li>\n
- Phantom Pairing<\/strong>: If users sitting outside an open meeting room pair with its display unintentionally, change
xConfiguration Proximity Pairing Audio Volume Mode<\/code> from static to Dynamic<\/code>, or lower the Audio Ultrasound MaxVolume<\/code> threshold from the default of 70 down to 50\u201360.<\/li>\n<\/ul>\n<\/span>How can administrators verify that ultrasound is being received?<\/span><\/h3>\n\n- In the Webex desktop application, click the user profile icon > Help<\/strong> > Diagnostics<\/strong>.<\/li>\n
- Select the Device Pairing<\/strong> tab.<\/li>\n
- Review the diagnostic checks:<\/li>\n
- Microphone Access<\/strong>: Checks if the OS grants microphone capture.<\/li>\n
- Ultrasound Detection<\/strong>: Indicates whether 20\u201322 kHz signals are actively present.<\/li>\n
- Network Reachability<\/strong>: Validates TCP port 443 connectivity between the computer and the detected endpoint IP.<\/li>\n<\/ol>\n
\n<\/span>Cisco Proximity App vs. Webex App: Feature and Lifecycle Comparison<\/span><\/h2>\nCisco introduced proximity pairing via a standalone application known simply as Cisco Proximity<\/strong>. Over time, this functionality was integrated directly into the flagship Webex App<\/strong>, which combines ultrasound pairing with modern cloud services, AirPlay, and Miracast.<\/p>\nCisco has officially
| | | | | | | | | | | |