Unified Communications
Unified Communications (UC) consolidates voice calling, video conferencing, instant messaging, presence indication, and file sharing into a single integrated platform accessible from any device. For organisations operating across multiple offices, field locations, and remote staff, UC eliminates the fragmentation that occurs when each communication channel operates independently with separate directories, authentication, and user experiences. A staff member in a regional office can see whether a colleague at headquarters is available, initiate a voice call that escalates to video, share a document during the conversation, and continue the discussion via messaging after the call ends, all within one interface using one identity.
- Unified Communications (UC)
- An integrated platform combining multiple real-time and near-real-time communication channels (voice, video, messaging, presence) with a consistent user experience and unified administration.
- Presence
- Real-time indication of a user’s availability and status (available, busy, away, in a meeting, do not disturb) automatically derived from calendar, call state, and manual settings.
- Federation
- The capability for UC systems in separate organisations to interoperate, allowing users to see presence, exchange messages, and conduct calls across organisational boundaries.
- Session Initiation Protocol (SIP)
- The signalling protocol used to establish, modify, and terminate voice and video sessions in IP-based communication systems.
- Extensible Messaging and Presence Protocol (XMPP)
- An open standard protocol for presence and instant messaging, enabling interoperability between different messaging platforms.
Component Integration Architecture
UC platforms achieve integration through a layered architecture where individual communication services connect to shared infrastructure components. The integration layer provides the unified experience by maintaining a single user directory, propagating presence across all channels, and enabling session handoff between modalities.
+------------------------------------------------------------------------+| USER INTERFACE LAYER || || +---------------+ +---------------+ +---------------+ || | Desktop | | Mobile | | Web | || | Client | | App | | Client | || | (Windows/Mac) | | (iOS/Android) | | (Browser) | || +-------+-------+ +-------+-------+ +-------+-------+ || | | | |+----------+------------------+------------------+-----------------------+ | | | v v v+------------------------------------------------------------------------+| INTEGRATION LAYER || || +-----------------+ +------------------+ +------------------+ || | Presence | | Identity & | | Session | || | Aggregation | | Directory | | Management | || | | | (LDAP/SCIM) | | | || +--------+--------+ +--------+---------+ +--------+---------+ || | | | || +--------v--------------------v---------------------v---------+ || | Message Bus / Event Router | || +-------------------------------------------------------------+ || |+------------------------------------------------------------------------+ | | | | v v v v+------------------------------------------------------------------------+| SERVICE LAYER || || +-------------+ +-------------+ +-------------+ +-------------+ || | Voice | | Video | | Messaging | | File | || | Service | | Service | | Service | | Sharing | || | (PBX/VoIP) | | (MCU/SFU) | | (IM/Chat) | | Service | || +------+------+ +------+------+ +------+------+ +------+------+ || | | | | |+------------------------------------------------------------------------+ | | | | v v v v+------------------------------------------------------------------------+| CONNECTIVITY LAYER || || +------------------+ +------------------+ +------------------+ || | PSTN Gateway | | SIP Trunking | | Internet/ | || | (legacy voice) | | (external calls) | | Cloud Services | || +------------------+ +------------------+ +------------------+ || |+------------------------------------------------------------------------+Figure 1: UC platform component architecture showing integration across user interfaces, shared services, and communication channels
The presence aggregation component collects status information from multiple sources: calendar systems indicate scheduled meetings, the voice service reports active calls, the messaging service tracks typing activity and last-seen timestamps, and users can set manual status overrides. The aggregator applies precedence rules to determine the composite presence shown to other users. A typical precedence order places “In a call” above “In a meeting” above “Available,” with “Do not disturb” overriding all automatic states when manually set.
The message bus enables real-time event propagation across services. When a user initiates a voice call, the voice service publishes a “call started” event that the presence aggregator consumes to update status. The messaging service subscribes to presence changes to display availability indicators next to contact names. This event-driven architecture decouples services while maintaining the integrated experience.
Session management handles the escalation and handoff scenarios that distinguish UC from standalone services. A user viewing a chat conversation can click to initiate a voice call with the same participant, and the session manager maintains the conversation context, allowing messages exchanged before and after the call to appear in a unified thread. When a voice call adds screen sharing, the session manager coordinates the media streams without requiring users to switch applications.
Deployment Models
UC platforms deploy in three primary configurations: fully cloud-hosted, entirely on-premises, and hybrid arrangements combining elements of both. The deployment model affects latency, data residency, operational complexity, and cost structure. Mission-driven organisations must evaluate these factors against their specific constraints, particularly when operating in regions with data sovereignty requirements or unreliable internet connectivity.
Cloud-Hosted UC
Cloud UC delivers all services from provider infrastructure, requiring only internet connectivity and client software at user locations. The provider manages servers, applies updates, maintains availability, and handles capacity scaling. Organisations pay subscription fees per user rather than capital expenditure for infrastructure.
+-------------------------------------------------------------------+| ORGANISATION LOCATIONS |+-------------------------------------------------------------------+| || +----------------+ +----------------+ +----------------+ || | Headquarters | | Regional | | Field | || | | | Office | | Office | || | +----------+ | | +----------+ | | +----------+ | || | | Clients | | | | Clients | | | | Clients | | || | +----+-----+ | | +----+-----+ | | +----+-----+ | || | | | | | | | | | || +------+---------+ +------+---------+ +------+---------+ || | | | |+---------+----------------------+----------------------+-----------+ | | | +----------------------+----------------------+ | | Internet | v+------------------------------------------------------------------+| CLOUD PROVIDER || || +-----------------------------------------------------------+ || | UC Platform | || | | || | +------------+ +------------+ +------------+ | || | | Voice | | Video | | Messaging | | || | +------------+ +------------+ +------------+ | || | | || | +------------+ +------------+ +------------+ | || | | Presence | | Directory | | Recording | | || | +------------+ +------------+ +------------+ | || | | || +-----------------------------------------------------------+ || || +------------------+ +------------------+ || | PSTN Breakout | | SIP Trunking | || | (voice to phone) | | (external lines) | || +------------------+ +------------------+ || |+------------------------------------------------------------------+Figure 2: Cloud-hosted UC with all services delivered from provider infrastructure
Cloud deployment suits organisations with reliable internet at all locations, no regulatory prohibitions on cloud data storage, and limited IT staff available for infrastructure management. The cloud provider’s geographic distribution of data centres can reduce latency for globally distributed organisations, provided the provider operates regions near user concentrations. A European provider with data centres in Amsterdam and Frankfurt serves European operations with sub-50ms latency, while users in East Africa connecting to the same infrastructure experience 150-250ms latency depending on routing.
Jurisdictional considerations
Cloud UC providers headquartered in the United States are subject to the CLOUD Act, which permits US government access to data regardless of storage location. Organisations handling sensitive data, particularly protection and safeguarding information, should evaluate provider jurisdiction alongside technical capabilities. European providers like Nextcloud Talk or self-hosted options avoid this exposure.
On-Premises UC
On-premises deployment places all UC infrastructure within organisation-controlled facilities. The organisation procures servers, installs software, manages updates, and maintains availability. This model provides complete data control and eliminates dependency on internet connectivity for internal communications.
On-premises UC requires substantial upfront investment in hardware and software licensing, plus ongoing operational commitment. A deployment supporting 500 users requires at minimum: two redundant servers for the UC platform (16 cores, 64GB RAM, 500GB SSD each), a session border controller for external calling, network infrastructure supporting quality of service, and storage for voicemail and recordings. Hardware costs range from £30,000 to £80,000 depending on vendor and redundancy requirements, with annual software maintenance fees of 15-20% of license cost.
The operational burden includes software updates (typically quarterly), security patching, certificate renewal, backup management, and capacity monitoring. Organisations without dedicated IT staff find this burden difficult to sustain. For a single-person IT function, on-premises UC consumes 4-8 hours weekly in routine maintenance, plus incident response time when issues arise.
Hybrid UC
Hybrid deployment distributes UC components between cloud and on-premises infrastructure according to specific requirements. Common patterns include cloud-hosted collaboration features (messaging, file sharing, presence) with on-premises voice infrastructure, or cloud platforms with on-premises session border controllers maintaining local PSTN connectivity.
Hybrid architectures address scenarios where neither pure cloud nor pure on-premises fits. An organisation with headquarters in a country requiring data localisation for voice recordings but field offices in remote locations benefits from local voice infrastructure at headquarters with cloud-based messaging accessible from anywhere. The complexity cost is a permanent dual-management burden: staff must maintain on-premises systems while also administering cloud services and managing the integration between them.
Distributed Organisation Patterns
Organisations with multiple offices face architectural decisions about where to place UC infrastructure components and how to route traffic between locations. Three patterns address different network topologies and resilience requirements.
Centralised Hub
All UC services run at a single location, typically headquarters, with branch offices connecting over WAN links. Voice and video traffic traverse the WAN for all calls, including those between users at the same branch office. This pattern minimises infrastructure footprint and simplifies administration but concentrates WAN bandwidth consumption and creates a single point of failure.
For a regional office with 30 users averaging 4 hours daily of voice calls and 2 hours of video meetings, centralised UC generates approximately 15 Mbps sustained WAN traffic during peak hours. The calculation: voice at G.711 codec consumes 87 kbps per call, video at 720p consumes 1.5 Mbps per stream. With 15 concurrent voice calls (50% of users) and 10 concurrent video participants (33% of users), bandwidth requirement is (15 × 87 kbps) + (10 × 1.5 Mbps) = 1.3 Mbps + 15 Mbps = 16.3 Mbps. Compression codecs reduce voice to 24 kbps (G.729) and video to 500 kbps (H.264 constrained), yielding (15 × 24 kbps) + (10 × 500 kbps) = 0.36 Mbps + 5 Mbps = 5.4 Mbps. Branch offices require at minimum this sustained capacity with 20% headroom, so 6.5 Mbps for compressed UC traffic.
Distributed with Central Control
Each major office hosts local media servers handling voice and video traffic, while central servers at headquarters manage signalling, presence, and directory services. Calls between users at the same office use local media paths, consuming no WAN bandwidth. Calls between offices route media directly between branch locations without transiting headquarters.
+------------------------------------------------------------------+| HEADQUARTERS || || +-----------------------------------------------------------+ || | Central UC Services | || | | || | +---------------+ +---------------+ +---------------+ | || | | Signalling | | Presence | | Directory | | || | | Server | | Server | | Server | | || | +-------+-------+ +-------+-------+ +-------+-------+ | || | | | | | || +----------+------------------+------------------+----------+ || | | | || +----------v------------------v------------------v----------+ || | Local Media Server | || | (voice/video for HQ users) | || +-----------------------------------------------------------+ || |+-----------------------------+------------------------------------+ | | WAN (signalling only for | inter-office calls) | +-------------------+-------------------+ | | v v+---------+----------+ +-----------+---------+| REGIONAL OFFICE | | FIELD OFFICE || | | || +----------------+ | | +----------------+ || | Local Media | | | | Local Media | || | Server | | | | Server | || +----------------+ | | +----------------+ || | | || Signalling ------->| | Signalling -------> || to HQ | | to HQ || | | || Media: local or <--+---------------+-> Media: local or || direct to peer | Direct media | direct to peer |+--------------------+---------------+---------------------+Figure 3: Distributed UC with central signalling and local media servers
This pattern reduces WAN bandwidth requirements by 60-80% for organisations where most communication occurs within offices rather than between them. The trade-off is infrastructure replication: each office with local media servers requires hardware, maintenance, and monitoring. A minimum deployment at a branch office needs a server capable of transcoding 10-20 simultaneous calls (4 cores, 16GB RAM) plus storage for local voicemail.
Fully Distributed
Each office operates an autonomous UC instance with local registration, media handling, and survivability. Federation protocols synchronise presence and enable inter-site communication. If WAN connectivity fails, each site continues operating independently with full local functionality.
Fully distributed UC suits organisations where field offices must operate autonomously during connectivity outages lasting hours or days. The complexity cost is substantial: each site requires complete UC infrastructure, and federated presence updates increase protocol traffic. Directory synchronisation between sites must handle conflicts when the same user record is modified at multiple locations during a partition.
Low-Bandwidth and Field Deployment
Field offices with constrained connectivity require specific architectural accommodations. Satellite links at 2 Mbps shared among 20 users cannot support standard UC traffic patterns. Three mechanisms enable UC operation in these environments: codec optimisation, traffic prioritisation, and local survivability.
Codec Optimisation
Voice and video codecs trade quality against bandwidth consumption. Standard office deployments use G.711 voice (87 kbps) and 1080p video (4 Mbps) for high quality. Field deployments configure aggressive compression: Opus voice codec at 16 kbps delivers intelligible speech at 80% bandwidth reduction, while 360p video at 300 kbps provides recognisable faces adequate for most meetings.
UC platforms expose codec policies configurable by site or user group. A field office policy might specify:
Voice: Primary codec: Opus at 16 kbps Fallback codec: G.729 at 8 kbps Packet loss concealment: enabled Jitter buffer: 200ms (versus 60ms standard)
Video: Maximum resolution: 640x360 Maximum framerate: 15 fps Maximum bitrate: 300 kbps Adaptive bitrate: enabled (floor: 100 kbps)With these settings, a video call with 4 participants consumes approximately 1.4 Mbps total: 300 kbps sending, plus 300 kbps receiving from each of 3 other participants, plus 16 kbps voice each direction. This fits within a 2 Mbps satellite link while leaving 0.5 Mbps for other traffic.
Traffic Prioritisation
Quality of Service (QoS) marking ensures UC traffic receives priority over bulk transfers when links become congested. Voice packets marked with DSCP EF (Expedited Forwarding) and video packets marked AF41 (Assured Forwarding class 4) receive preferential treatment from routers configured for differentiated services.
Local routers at field offices must enforce these priorities at the WAN interface. Without prioritisation, a large email attachment upload saturates the link and introduces 500ms+ jitter into concurrent voice calls, making conversation impossible. With prioritisation, voice maintains 50ms jitter while the email transfer slows to use remaining capacity.
Satellite latency
Geostationary satellite links introduce 600-800ms round-trip latency regardless of bandwidth. This latency affects voice call naturalness and video synchronisation but does not prevent UC operation. Users adapt to the delay by allowing longer pauses between speakers. UC platforms should disable echo cancellation features designed for low-latency links, as these interfere with satellite’s natural delay pattern.
Local Survivability
When the WAN link fails, field offices with local UC infrastructure continue internal operations. Local users call each other, access cached presence, and retrieve voicemail stored on local servers. Messages to remote users queue for delivery when connectivity restores.
Survivability requires local infrastructure: a UC server capable of standalone registration, local PSTN connectivity for external calls (if available), and cached directory data. The caching strategy determines how current presence and directory information appears during an outage. A 4-hour cache means presence shows last-known status from up to 4 hours ago, acceptable for most scenarios but potentially misleading if a colleague became unavailable just before the outage.
Federation and Interoperability
Federation enables UC systems in separate organisations to interoperate, allowing staff at one organisation to see presence, exchange messages, and conduct calls with contacts at partner organisations. This capability matters for coalitions, consortia, and organisations with extensive external collaboration.
+------------------------------------------------------------------+| ORGANISATION A || || +-----------------------------------------------------------+ || | UC Platform A | || | | || | +---------------+ +---------------+ +---------------+ | || | | Users | | Presence | | Federation | | || | | @org-a.org | | Service | | Gateway | | || | +---------------+ +---------------+ +-------+-------+ | || | | | || +------------------------------------------------+----------+ || | |+---------------------------------------------------+--------------+ | | SIP/XMPP | (federated) | +---------------------------------+ | | Federation established via: | - DNS SRV records | - TLS certificate validation | - Access control policies | +---------------------------------+ |+---------------------------------------------------+--------------+| ORGANISATION B || | || +------------------------------------------------+----------+ || | UC Platform B | | || | | | || | +---------------+ +---------------+ +-------+-------+ | || | | Users | | Presence | | Federation | | || | | @org-b.org | | Service | | Gateway | | || | +---------------+ +---------------+ +---------------+ | || | | || +-----------------------------------------------------------+ || |+------------------------------------------------------------------+Figure 4: Federation between two organisations’ UC platforms
Federation operates through standardised protocols, primarily SIP for voice/video and XMPP for messaging/presence. When establishing federation, both organisations must:
- Publish DNS SRV records indicating federation endpoints
- Configure TLS certificates trusted by the partner
- Define access policies specifying what federated users can do
- Test bidirectional connectivity through firewalls
Access policies control federation granularity. A restrictive policy permits only presence viewing and instant messaging with explicitly approved external contacts. A permissive policy allows any user to initiate voice and video calls with any federated contact. Most organisations implement moderate policies: open messaging with approved partner domains, voice calls permitted, video calls requiring explicit approval.
Cross-Platform Federation
Federation between different UC platforms (for example, Microsoft Teams federating with Cisco Webex) requires additional gateway infrastructure. Native protocols differ between vendors, necessitating translation. Gateway products from vendors like Poly or AudioCodes bridge protocol differences, presenting a SIP interface to one platform and a proprietary interface to another.
Cross-platform federation introduces limitations. Presence granularity reduces to basic states (available, busy, offline) as advanced states do not translate between platforms. Features like message reactions, threaded replies, or meeting scheduling may not traverse the gateway. Voice and video calls work reliably once established, but call setup takes longer due to protocol translation.
For organisations requiring extensive cross-platform federation, evaluating gateway products involves testing specific feature combinations rather than relying on vendor claims. A federation link that works for basic messaging may fail when users attempt to share screens or transfer files.
Security and Compliance
UC platforms concentrate sensitive communications data: voice recordings, meeting content, chat logs, and file transfers. Security architecture must address data protection, access control, and compliance requirements.
Encryption
UC traffic requires encryption both in transit and at rest. In-transit encryption protects communications crossing networks: TLS 1.3 for signalling, SRTP (Secure Real-time Transport Protocol) for voice and video media. At-rest encryption protects stored recordings, voicemail, and message logs.
End-to-end encryption (E2EE) extends protection so that even the UC platform operator cannot access content. E2EE voice and video calls encrypt media with keys known only to participants, not the server facilitating the call. E2EE messaging encrypts content client-to-client. Platforms offering E2EE include Signal protocol implementations (used by Element/Matrix), Oaranke, and optionally Oibra Teams.
E2EE creates compliance tensions. Recording calls for quality assurance or regulatory requirements becomes impossible when the platform cannot decrypt content. Organisations subject to recording mandates must either disable E2EE or implement client-side recording that captures decrypted content locally.
Access Control
UC access control integrates with organisational identity management. Users authenticate through the identity provider (IdP), receiving authorisation claims that determine UC capabilities. Role-based policies assign permissions: standard users can make calls and send messages; supervisors can monitor calls in their team; administrators can modify system configuration.
External access policies control guest participation. Meeting guests from outside the organisation might receive permission to join scheduled meetings but not to initiate calls or view internal presence. Partner federation policies (discussed above) govern ongoing relationships with specific external organisations.
Compliance Recording
Regulated industries require communications recording and retention. Financial services must retain trading-related communications for 5-7 years. Healthcare must protect and retain patient communications. Even organisations outside regulated industries may want recording for training, dispute resolution, or institutional knowledge preservation.
UC platforms support compliance recording through integration with archiving systems. The recording architecture captures calls and meetings, applies retention policies, enables search and retrieval, and enforces legal hold when required. Policy-based recording can capture all communications, specific user groups, or communications matching criteria (international calls, communications with certain contacts).
Storage requirements for compliance recording are substantial. Voice recording at reasonable quality (G.711, 87 kbps mono) generates 650 MB per user per month assuming 40 hours of calls. Video recording at 720p generates 13 GB per user per month assuming 40 hours of meetings. A 500-user organisation with comprehensive recording and 7-year retention requires approximately 55 TB for voice alone, or 550 TB including video. Cloud archiving services charge £0.01-0.03 per GB per month; the voice archive costs £550-1,650 monthly, video archive £5,500-16,500 monthly.
Mobile UC Integration
Mobile devices represent a primary UC endpoint for staff working outside offices. Mobile UC apps must provide feature parity with desktop clients while accommodating mobile constraints: smaller screens, cellular network variability, battery consumption, and context switching between mobile and desktop.
Mobile Client Architecture
Mobile UC clients connect to the platform over cellular or Wi-Fi networks, maintaining a persistent connection for presence updates and incoming call notification. Push notifications wake the app for incoming calls when it is backgrounded or the device is asleep.
+------------------------------------------------------------------+| MOBILE DEVICE || || +-----------------------------------------------------------+ || | UC Mobile App | || | | || | +------------+ +------------+ +------------+ | || | | Voice | | Video | | Messaging | | || | | Client | | Client | | Client | | || | +-----+------+ +-----+------+ +-----+------+ | || | | | | | || | +-----v---------------v---------------v------+ | || | | Connection Manager | | || | | - Network selection (WiFi/cellular) | | || | | - Connection persistence | | || | | - Bandwidth adaptation | | || | +---------------------+----------------------+ | || | | | || +------------------------+----------------------------------+ || | || +------------------------v----------------------------------+ || | OS Push Notification Service | || | (APNs for iOS, FCM for Android) | || +------------------------+----------------------------------+ || | |+---------------------------+--------------------------------------+ | | Internet (WiFi or Cellular) | v+------------------------------------------------------------------+| UC PLATFORM || || +-----------------------------------------------------------+ || | Mobile Gateway | || | - Push notification dispatch | || | - Mobile-optimised media | || | - Single sign-on integration | || +-----------------------------------------------------------+ || |+------------------------------------------------------------------+Figure 5: Mobile UC client architecture with push notification integration
Battery optimisation requires careful connection management. Maintaining a constant socket connection for presence drains battery within hours. Mobile clients instead use push notifications for incoming events, establishing connections only when actively communicating. Presence updates aggregate and batch, reducing network transactions.
Network Handoff
Mobile devices frequently transition between Wi-Fi and cellular networks, and between cellular towers. UC calls should survive these transitions without dropping. The connection manager in the mobile client monitors network state, prepares backup connections in advance, and switches traffic when transitions occur.
Network handoff mechanisms vary by platform. Session border controllers (SBCs) with mobile support maintain call state across IP address changes. ICE (Interactive Connectivity Establishment) renegotiation allows endpoints to update media paths during calls. Some platforms implement proprietary reconnection that replays media from server buffers during brief disconnections.
Users experience handoff as momentary audio gaps (0.5-2 seconds) when successful, or dropped calls when unsuccessful. Testing handoff behaviour with specific platforms on specific networks reveals actual reliability. Enterprise Wi-Fi deployments with proper inter-access-point roaming (802.11r/k/v) provide better handoff than consumer-grade networks.
Technology Options
UC platform selection considers deployment model, feature requirements, integration capabilities, and organisational constraints. Open source options provide full control and avoid licensing costs at the expense of operational complexity. Commercial platforms reduce operational burden but introduce vendor dependency and ongoing subscription costs.
Open Source Platforms
Nextcloud Talk integrates with the Nextcloud collaboration platform, providing messaging, video conferencing, and screen sharing. Voice calling requires additional integration with a SIP platform. Nextcloud Talk runs on standard Linux servers (4 cores, 8GB RAM supports 50 concurrent video participants), with clients for web, desktop, and mobile. Federation uses standard protocols, enabling interoperability with other Nextcloud instances and potentially other platforms. Data remains entirely within organisational infrastructure.
Matrix (Element) provides a decentralised messaging and VoIP platform built on the Matrix protocol. Element is the primary client application. Matrix emphasises federation and interoperability, with bridges available to other platforms including Slack, IRC, and XMPP. End-to-end encryption is standard. Video conferencing through Element Call supports meetings up to 100 participants in recent versions. Self-hosting requires a Synapse or Dendrite server; hosted options exist from Element and third parties.
Jitsi Meet focuses on video conferencing with integrated messaging during meetings. Jitsi provides no persistent chat between meetings, positioning it as a meeting tool rather than comprehensive UC. Installation is straightforward (single server, Docker deployment available), and the platform handles 35-50 concurrent participants per server core. Jitsi integrates with external messaging and voice platforms rather than providing them natively.
Commercial Platforms
Microsoft Teams dominates the commercial UC market, particularly among organisations using Microsoft 365. Teams provides messaging, video meetings (up to 1,000 participants or 20,000 in view-only webinars), voice calling (with appropriate licensing), file sharing integrated with SharePoint, and extensive third-party app integrations. Microsoft 365 Nonprofit licensing provides Teams at reduced cost for eligible organisations. Teams operates entirely in Microsoft cloud infrastructure (Microsoft-managed data centres globally, subject to CLOUD Act as a US company).
Google Workspace (formerly G Suite) includes Google Meet for video conferencing and Google Chat for messaging. Voice calling requires integration with third-party providers or Google Voice (limited geographic availability). Google Workspace Nonprofit provides discounted access. Like Microsoft, Google’s platforms operate in US-headquartered cloud infrastructure.
Cisco Webex offers enterprise-grade UC with strong video conferencing heritage. Webex provides hybrid deployment options including on-premises infrastructure for organisations requiring it. Licensing costs exceed Microsoft and Google for equivalent functionality, though nonprofit discounts exist.
Zoom focuses on video meetings with Zoom Phone providing voice calling in recent years. Zoom’s meeting experience is polished and familiar to most users. Zoom for Nonprofits provides discounted licensing. Zoom operates primarily in cloud but offers Zoom Meetings on-premises deployment for video infrastructure.
Selection Considerations
Organisations with existing Microsoft 365 deployments find Teams integration compelling: single identity, unified admin console, no additional licensing for most features. The trade-off is deep Microsoft dependency and data jurisdiction concerns.
Organisations prioritising data sovereignty and open standards gravitate toward Nextcloud Talk or Matrix, accepting higher operational complexity. Matrix’s federation capability suits consortia where multiple organisations want interoperable UC without centralising on one vendor.
Organisations with limited IT capacity and no existing platform investment should evaluate total cost of ownership including operational burden. A cloud UC subscription at £8-15 per user monthly may cost less than self-hosted open source when accounting for staff time maintaining infrastructure.
Implementation Considerations
For Organisations with Limited IT Capacity
Start with cloud UC requiring minimal infrastructure: Microsoft Teams if already using Microsoft 365, Google Workspace if using Google, or Zoom as standalone. Accept the operational simplicity of vendor-managed infrastructure. Configure basic policies (meeting settings, guest access) but avoid customisation that creates maintenance burden.
If data sovereignty concerns preclude major cloud providers, evaluate hosted Nextcloud providers in appropriate jurisdictions. Hosted Nextcloud delivers the benefits of open source (data control, no vendor lock-in to proprietary protocols) without self-hosting operational burden.
Avoid on-premises UC deployment with single-person IT functions. The maintenance burden of patching, certificate management, backup verification, and incident response exceeds available capacity. If regulatory requirements mandate on-premises, engage managed service providers for UC operations.
For Organisations with Established IT Functions
Evaluate UC platforms against integration requirements: identity provider federation (SAML, OIDC), directory synchronisation, API access for automation, and compliance recording capabilities. Pilot deployments with 50-100 users before organisation-wide rollout reveal integration issues and user experience concerns.
Plan migration carefully when replacing existing communications tools. Users develop workflows around current tools; changing messaging platforms disrupts these workflows regardless of new platform capability. Phase migrations by department or location, maintaining interoperability between old and new systems during transition.
For distributed organisations with field offices, architect UC for the lowest-capability locations. Configure codec policies, deploy local infrastructure where connectivity warrants, and test satellite and low-bandwidth scenarios before declaring deployment complete.
For Federated Organisations
Confederations of autonomous entities face UC decisions at confederation and entity levels. A lightweight approach establishes federation between entities’ independent UC platforms, enabling cross-entity presence and messaging while preserving entity autonomy. A heavier approach deploys shared UC infrastructure managed centrally, simplifying administration but creating governance tensions over policy and data.
Federation typically suits organisations where entities have existing UC investments or strong autonomy requirements. Shared platforms suit new confederations or those prioritising unified experience over entity independence.