Businesspeople meet in a conference room, joining a secure video call with colleagues and reviewing presentation charts.
Joining another company’s video meeting is becoming less of a technical obstacle. Keeping the right features, permissions and information available once everyone is connected is the harder problem. That is the argument Pexip’s Jordan Owens makes in UC Today’s examination of meeting interoperability—and it presents a useful challenge for organizations managing Microsoft Teams Rooms alongside Zoom, Google Meet and Webex. A successful connection is not the same thing as a complete working experience.

Microsoft’s documentation gives that distinction practical substance. Teams Rooms offers both WebRTC-based Direct Guest Join and SIP-based cross-platform joining, with different licensing requirements, display capabilities and content-sharing options. Neither should be mistaken for a universal bridge carrying every meeting feature, organizational permission and AI assistant across platforms.

The immediate task for IT is to choose and configure the right connection method. The longer-term question raised by Owens is more ambitious: can people bring their organization’s information and AI capabilities into meetings without losing control of the data?

Businesspeople meet in a conference room, joining a secure video call with colleagues and reviewing presentation charts. What changed—and which rooms benefit​

The interoperability timeline needs some precision. UC Today points to Teams Rooms joining Zoom through Direct Guest Join in 2022 as an earlier milestone. That is useful historical context, not a claim that cross-platform videoconferencing began in 2022. The more recent developments broaden the available connections and improve what particular endpoints can do.

Google’s February 3, 2026 announcement introduced built-in, two-way interoperability between ChromeOS-based Google Meet hardware and Windows-based Microsoft Teams Rooms. Meet hardware could join Teams meetings, while Windows Teams Rooms could join Meet meetings. Those operating-system boundaries were explicit at launch; “Google Meet and Teams work together” was never a sufficient deployment specification.

Google said its setting would be enabled by default, could be disabled by organizational unit, and would not overwrite existing Pexip settings for units already using them. Its rollout schedule separated administrative visibility, beginning February 3, from end-user visibility, beginning February 16 with a gradual rollout lasting up to 15 days.

Microsoft’s subsequent release notes document Google Meet Direct Guest Join for Teams Rooms on Android in version 1449/1.0.96.2026261804, released in September 2026, supporting calendar joining or joining by meeting ID. Separately, the Android release notes list enhanced cross-platform joining through SIP. These are distinct connection methods, not interchangeable names for the February announcement.

Windows administrators also have an earlier SIP milestone to recognize: Microsoft lists enhanced cross-platform SIP meetings in Teams Rooms on Windows 5.4.210.0, dated September 29, 2025. Its stated capabilities include higher-resolution video, dual displays and HDMI ingest, with a calling plan supplied through a Cloud Video Interop partner.

The practical conclusion is straightforward: inventory the room operating system, application version, enabled providers and calling arrangements. A platform logo on a purchasing spreadsheet does not establish the experience users will receive.

When built-in guest access is enough​

Owens, whom UC Today identifies as Pexip’s CTO for the Americas, makes a useful concession: organizations standardized on one meeting platform may find native interoperability entirely adequate when rooms only occasionally attend outside meetings. His argument for specialist services centers instead on mixed environments, advanced features and governance requirements.

That distinction deserves consideration, but so does its commercial context. Pexip sells interoperability services, and Owens explicitly describes customer discussions moving from explaining interoperability to explaining Pexip’s value. This is a vendor’s assessment, not independent evidence that every multinational needs another service subscription.

A sensible evaluation starts with the work rather than the supplier. Consider two hypothetical requirements:

  • A small room occasionally joins a customer’s meeting to listen, speak and view a presentation.
  • A frequently used project room joins another division’s platform and must transmit local presentation content while using two front-of-room displays.

Those are different acceptance tests. Treating them as the same procurement category invites either unnecessary expense or disappointed users.

Microsoft’s published comparison explains why:

CapabilityDirect Guest JoinCross-platform SIP join
Connection technologyWebRTCSIP video
Maximum listed send/receive video720p at 30 fps1080p at 30 fps
Front-of-room displaysOneTwo
Receive shared contentSupportedSupported
Send HDMI or content-camera contentNot supportedSupported
Teams Rooms licenseBasic or ProPro
Paid SIP dialing planNot requiredRequired

These are Microsoft’s documented capabilities, not guaranteed performance measurements. Microsoft also warns that third-party features vary by platform and can change.

One particularly important distinction concerns the lobby. Microsoft lists platform-dependent lobby control for SIP, but lists lobby authentication or bypass as unavailable for both methods. A discussion about reducing lobby friction therefore must not become a promise that buying SIP interoperability automatically lets rooms bypass admission controls.

The buying rule should be simple: require evidence for the specific workflow, not an assurance that the room offers a “native-like” experience.

Configure the connection before blaming the platform​

For Teams Rooms administrators, several mundane configuration details can determine whether interoperability works at all. Microsoft’s setup guidance covers room-mailbox processing, meeting-link preservation, network access and device settings. These dependencies deserve attention before an organization concludes that it needs a different interoperability architecture.

1. Prepare the room mailbox​

Third-party joining depends on information in the invitation’s message body. Microsoft instructs administrators to connect to Exchange Online PowerShell and configure the room resource mailbox to process external invitations without deleting that body:

Set-CalendarProcessing <UserPrincipalName> -ProcessExternalMeetingMessages $True -DeleteComments $False

Replace <UserPrincipalName> with the actual room mailbox UPN. This is an administrator operation, not something meeting participants should run on their PCs.

As an acceptance test, forward a representative external invitation to the room and confirm that it appears with a usable join button. If it does not, investigate calendar processing and invitation contents before troubleshooting cameras or microphones.

2. Preserve recognizable meeting links​

Microsoft warns that third-party URL-rewriting tools can change meeting links sufficiently to prevent Teams Rooms from recognizing them. Its guidance says Microsoft Defender for Office 365 Safe Links needs no additional steps, while other rewriting products may require exceptions for trusted meeting-service URLs.

The appropriate response is a targeted review with the messaging-security team—not disabling link protection across the organization. Compare a failing invitation with its original and establish whether rewriting is actually responsible before changing security policy.

3. Check the network path​

Direct Guest Join connects the room directly to the external provider’s website. Microsoft says firewalls and web filters must permit the relevant traffic without requiring authentication, with suitable quality-of-service treatment where applicable.

SIP follows a different route. Microsoft’s SIP/H.323 documentation says calls pass through Microsoft 365 to the calling-plan provider and require no additional firewall or network rules when Teams Rooms is already working. That statement applies to this routing arrangement; it does not remove the separate connectivity requirements of Direct Guest Join.

4. Enable the intended providers​

Microsoft documents centralized configuration through the Teams Rooms Pro Management portal:

  1. Select Rooms, then the target room.
  2. Open Settings, then Meetings.
  3. Enable the required third-party platforms.
  4. Select Apply.

Local configuration differs by operating system. On Windows, use More → Settings, authenticate with device administrator credentials, and open Meetings. Enable the provider, choose room information or custom joining information, then select Save and exit; the device restarts. On Android, use More → Settings → Teams admin settings, authenticate, open Meetings, and enable the provider toggles.

Test the room as an ordinary participant afterward. Success means more than entering the call: verify incoming and outgoing audio, camera video, presentation viewing and any required content-sharing behavior.

SIP adds capabilities—and deployment responsibilities​

SIP joining requires more than enabling a meeting-provider toggle. Microsoft specifies a Teams Rooms Pro license, an agreement with a certified Cloud Video Interop provider offering the required dialing capability, provider-supplied AreaCode information, and a video teleconferencing policy assigned to the room resource account. SIP/H.323 dialing is disabled by default.

Microsoft’s policy workflow uses Teams PowerShell:

  1. Create the policy with New-CsTeamsRoomVideoTeleConferencingPolicy.
  2. Supply the provider’s AreaCode and explicitly choose incoming-call settings.
  3. Inspect configuration with Get-CsTeamsRoomVideoTeleConferencingPolicy.
  4. Assign the policy to the intended room accounts with Grant-CsTeamsRoomVideoTeleConferencingPolicy.

For a pilot, a deliberately scoped policy is preferable to an unexamined tenant-wide change. Test representative rooms and meeting providers, document expected behavior, and expand only after the workflows pass.

There is also a fallback trap worth putting directly into user instructions. Microsoft says a SIP-enabled room can fall back to WebRTC Direct Guest Join when a calendar invitation lacks a SIP dial string. That automatic fallback applies to the calendar join button. Joining by meeting ID can fail when the target meeting lacks SIP capability.

This makes “try joining from the room calendar” a documented troubleshooting step, not merely conference-room folklore. Administrators should test both entry methods rather than assuming that a successful calendar join proves join-by-ID will behave identically.

Why the next question is about data​

Owens’s longer-term proposition is that interoperability should preserve access to a participant’s organizational information and AI tools, regardless of which service hosts the meeting. His examples include a Zoom-oriented organization wanting its AI Companion experience in a Teams-hosted meeting, and a Teams user wanting OneDrive information available while attending elsewhere. UC Today presents these as ambitions, not an announced technical architecture or launch schedule.

That distinction matters. The interview does not establish that a Teams Rooms join method transports an AI assistant, document permissions or an organization’s governance policies into another service.

There are at least three separate requirements to evaluate:

  • Connectivity: Can the endpoint enter the meeting and exchange media?
  • Working experience: Can participants present, use the displays and access necessary meeting controls?
  • Information governance: Which identities and services may access, process, retain or share the resulting data?

This is an evaluation framework, not a claim that vendors implement three neatly separated technical layers. Its value is preventing a successful video-call demonstration from being treated as proof of secure information exchange.

Likewise, accessing a document personally is not the same requirement as permitting a meeting assistant to process that document. An enterprise assessing cross-platform AI should ask vendors to demonstrate the actual identity, authorization and data-handling behavior rather than infer it from the presence of a familiar assistant name.

Make governance part of the acceptance test​

Owens says scrutiny of data sovereignty and control extends beyond government into healthcare, financial services, insurance and government suppliers. That is his observation of customer requirements, not quantified market research or a statement that all those sectors face identical obligations.

For IT teams, the useful response is a concrete review checklist:

  • Identity: Is the participant represented by a person, room resource account or guest identity?
  • Authorization: What allows a document or assistant to access meeting information?
  • Processing: Which services handle media, transcripts, summaries and attachments?
  • Location: Where is each data category processed and stored?
  • Retention: Who controls deletion, preservation and subsequent access?
  • Auditability: Can administrators establish what was accessed, shared or retained?
  • Host controls: What happens when an external organizer restricts admission, recording or assistant participation?

These are recommended acceptance questions, not assertions that a particular product answers them inadequately. Ask for answers tied to the purchased service, deployment model and actual meeting workflow.

A specialist interoperability provider may address some requirements, but its involvement should itself be included in that review. More capable connectivity is not automatic evidence of better governance, just as a built-in connection is not automatic evidence of sufficient governance.

The practical bottom line​

The strongest takeaway is not that native meeting interoperability is becoming obsolete. It is that organizations should stop using “the room joined” as their only success criterion.

Start with the documented connection options. Verify the room versions, configure invitations and providers correctly, and test the features users actually need. Add SIP or specialist services where measured requirements justify their dependencies. Keep ambitions for portable AI and organizational data separate from capabilities demonstrated today.

The join button can get everyone into the conversation. Whether they can work effectively—and whether the organization retains appropriate control—is the more important test.

 

References

  1. Why Meeting Interoperability’s Next Phase Is About Data - UC Today UC Today 2026-11-09T09:01:00.500000+00:00
  2. Release notes for Microsoft Teams Rooms - Microsoft Teams | Microsoft Learn learn.microsoft.com
  3. Google Meet and Teams Rooms Add Two-Way Interoperability — UC Today uctoday.com