If you support a Cisco Unified Communications environment, you already know that Cisco Jabber’s screen sharing feature is one of those “it works… until it doesn’t” capabilities.
On paper, desktop sharing in Jabber is simple. In practice, I’ve seen it fail silently, fail selectively, or fail entirely—often after infrastructure changes that had nothing to do with Jabber itself.
One of the most common and frustrating errors users encounter is:
“Failed to join share – Could not connect to the remote host”
What makes this error particularly painful is that:
- Jabber calls still work
- IM and presence are unaffected
- Video may work perfectly
- Only screen sharing fails
This article walks through the real root causes, not just the checkbox-level fixes, and explains why the problem happens, how to verify the configuration properly, and how to avoid the issue recurring in enterprise environments.
Understanding How Cisco Jabber Screen Sharing Actually Works
Before fixing the issue, it’s important to understand what Jabber is doing under the hood.
Cisco Jabber screen sharing relies on:
- BFCP (Binary Floor Control Protocol) for presentation control
- RTP/SRTP media streams for desktop content
- CUCM SIP Profiles to allow presentation sharing
- Firewall traversal for dynamic media ports
If any one of these components is misconfigured, Jabber fails with the generic “remote host” error.
From experience, this is almost never a Jabber client bug—it’s almost always CUCM or firewall configuration drift.
The Two Real Requirements for Jabber Screen Sharing to Work
After troubleshooting dozens of these cases, the fix always comes down to two non-negotiable requirements:
- BFCP must be enabled on the SIP Profile used by the CSF device
- Firewall ports must allow BFCP and desktop sharing media
If either is missing, screen sharing fails—even though calls continue to work.
Step 1: Verify BFCP Is Enabled on the Correct SIP Profile
This is the most common root cause.
Many environments have:
- Multiple SIP profiles
- Legacy profiles created years ago
- Profiles copied from trunks without BFCP enabled
Why This Matters
Cisco Jabber (CSF devices) inherits its capabilities from the SIP Profile, not from the device itself.
If BFCP is disabled:
- Jabber can initiate a call
- Jabber can send video
- Jabber cannot negotiate presentation sharing
The result?
“Could not connect to the remote host”
How to Enable BFCP in CUCM (Correctly)
Log into Cisco Unified CM Administration and follow these steps:
- Navigate to:
Device → Device Settings → SIP Profile - Identify the SIP Profile used by your CSF devices
(Check an affected Jabber user under Device → Phone → CSFxxxx) - Open the SIP Profile and scroll to:
Trunk Specific Configuration - Enable:
✔ Allow Presentation Sharing Using BFCP - Click Save
⚠️ Important:
Changing a SIP Profile does not apply automatically to devices.
Apply the SIP Profile to Jabber Devices
You must now apply (or re-apply) the SIP profile:
- Single device:
- Go to Device → Phone
- Open the CSF device
- Confirm the correct SIP Profile is selected
- Save
- Multiple devices:
- Use Bulk Administration Tool (BAT)
Finally:
- Reset the CSF devices
- Ask users to restart Cisco Jabber
Skipping this step is a common reason the fix appears not to work.
What Is BFCP and Why Jabber Depends on It
Binary Floor Control Protocol (BFCP) is defined in RFC 4582 and is responsible for:
- Negotiating who can share
- Starting and stopping presentation streams
- Managing desktop sharing “floor control”
In Cisco environments:
- CUCM acts as the BFCP signaling controller
- Media flows directly between endpoints
- Firewalls must allow dynamic media ports
Since CUCM 9.0(1), BFCP is enabled by default in newer SIP profiles—but older or custom profiles often don’t have it enabled.
This explains why:
- Older Jabber users may work
- New Jabber users fail
- Only certain locations are affected
Step 2: Validate Firewall Ports for Jabber Screen Sharing
If BFCP is enabled and the issue persists, the firewall is the next suspect.
In tightly controlled enterprise networks, firewall teams often:
- Allow voice RTP
- Allow signaling
- Block “unknown” high-range ports
Unfortunately, desktop sharing lives in those high-range ports.
Required Ports for Cisco Jabber Screen Sharing
The following ports must be allowed between Jabber clients (and across VPN if applicable):
Voice, Video, and Desktop Sharing Media
UDP 16384 – 32766
Protocol: RTP / SRTP
Purpose: Audio, video, and BFCP desktop sharing
Jabber-to-Jabber Media (Hybrid / IM-based calls)
UDP 33434 – 33598
Protocol: RTP / SRTP
Purpose: Audio and video media
IM-Only Desktop Sharing (Windows Clients)
TCP 49152 – 65535
Protocol: RDP
Applies to: Cisco Jabber for Windows
Desk Phone Video Interface (Optional)
TCP 8000
Purpose: Video stream from desk phone to Jabber client
Real-World Firewall Gotchas
From experience, common mistakes include:
- Allowing RTP only from phones, not soft clients
- Blocking high TCP ephemeral ports on VPN
- Stateful firewalls timing out BFCP sessions
- SSL inspection interfering with media negotiation
If Jabber works internally but not over VPN, this is almost always the cause.
How I Usually Troubleshoot This in Production
My standard troubleshooting approach looks like this:
- Confirm SIP Profile BFCP setting
- Check CSF device SIP Profile assignment
- Reset device and restart Jabber
- Test internal LAN sharing
- Test VPN sharing
- Review firewall logs for dropped UDP/TCP sessions
If BFCP is correct and firewall logs show blocked ports, you’ve found your culprit.
Preventing This Issue from Returning
To avoid seeing this again:
- Standardise one SIP Profile for all CSF devices
- Document BFCP as a mandatory requirement
- Include Jabber ports in firewall change templates
- Test screen sharing after CUCM upgrades
- Test again after firewall rule clean-ups
Screen sharing is often the first feature to break when security hardening occurs.
Final Thoughts: Why This Error Is So Misleading
The error message:
“Could not connect to the remote host”
…makes it sound like:
- DNS is broken
- The user is offline
- Jabber is unstable
In reality, it almost always means:
- BFCP negotiation failed
- Media ports were blocked
Once you understand that, the fix becomes straightforward—and repeatable.
If you support Cisco Jabber at scale, this is one of those issues worth documenting internally, because it will happen again.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.