Apple and Cisco announced they’ve made a deal that gives Apple users a fast lane on networks run on Cisco devices. As you surely recall, the FCC banned fast lanes on America’s Internet access networks in February in its infamous 2015 Open Internet rules. So why are Apple and Cisco thumbing their noses at the FCC and how will the agency react?

The Apple/Cisco deal means a couple of different things: it’s going to be easier for Apple users to connect to Cisco routers, so one part of the fast lane is simply quick deployment. And for another, Cisco devices will be able to manage traffic streams to and from Apple devices of all kinds, whether they run OS X, iOS, or watchOS. This traffic management will allow users of Cisco’s VoIP systems to interoperate with Apple devices better, for Apple devices to use Cisco Telepresence better, and for things like WebEx to work really well on Cisco networks.

All of this depends on some enhancements to that other IOS, the one with the capital I, which is the operating system for the big Cisco routers. Cisco routers won’t automatically recognize Apple devices and give them special treatment, but they will respond to customer configurations that enable this behavior. And it’s all perfectly legal.

Cisco and Apple can do these things because Cisco routers managing corporate networks are outside the reach of the FCC, which only has a role in public communication by wire or radio. Despite the FCC’s regulations on ISP networks, private networks can still operate any way they see fit. And that’s a good thing, because private networks are where the innovation comes from.

When devices and routers can develop in Tandem, interesting things can happen. One scenario mentioned in the press stations concerns YouTube, and there’s another mention of Telepresence. These are both video apps, but they’re very different in operation.

YouTube is a one-way application that looks pretty much the same on a network analyzer as a web page, only longer. It uses the HTTP protocol, delivers packets in clumps, and essentially transfers files from a server to a client, where they’re rendered and displayed by a client that owes its lineage to the web.

Telepresence is a whole different ballgame. It uses RTP to manage a bi-directional, real-time stream between peers who act as both producers and consumers of audio/video information at the very same time. It’s packets don’t look anything at all like web page when you view them on an analyzer. Telepresence can’t lean on a buffer for help if there’s a delay in the arrival of packets at the destination; audio and video have to be in sync, and delays have to be less than 150 ms from end to end for the illusion of presence to take hold.

While YouTube puts the viewer into the world of the story it’s telling – usually a fictional one – Telepresence is an entirely different illusion, a projection of presence into a remote location synchronized with a simultaneous reception of the illusion that the conference partner is projecting. While entertainment video destroys reality and replaces it with a story, conferencing simply destroys distance and creates an intimate experience out of thin air. They’re both magical, but in entirely different ways.

Because Telepresence is not delay-tolerant while streaming is – thank to that buffer – it’s obvious how the two applications and their respective data streams – should be managed: Telepresence data streams should have a fast lane, and streaming should get whatever network capacity is left over after Telepresence is happy. This is the only sensible way to combine a delay-tolerant stream alongside a delay-intolerant one.

This is what companies want to do with their private networks, and as long as they confine this behavior to their own campuses – no matter how far-flung – they escape the wrath of the regulator. As far as I can tell, the deal is non-exclusive, so Cisco could do the same thing for the headachy world of Android with all its versions, vendors, and variations, but in practice that would be much more complicated. And Apple can do a deal with Brocade, Huawei, or Juniper if they were so inclined, but the leverage wouldn’t be as strong.

So we should be seeing some enhancements to the Apple and Cisco software to facilitate these fast lanes and then the firms will amass some experience on fast lanes. In four or five years, the whole complexion of the feared fast lane may very well change.

But in the meantime we can’t try this at home.