ConfigureHow

Casting is two mechanisms, not one

By Maria Caspar. Published . 9 min read

Casting is two unrelated mechanisms sharing one verb. In the first, your phone hands the television a URL and a play command and then stops carrying anything: the TV opens its own connection to the content server. In the second, your phone captures its screen, encodes it into a video stream, and pushes that stream across the room in real time. Picture quality, battery drain, whether you can walk out with the phone, and whether an app refuses to play at all are all decided by which of the two a given button triggered. The button almost never says.

Handoff: the television is the client

Google's architecture documentation is explicit about who fetches the video. A Sender "initiates the Cast session and manages the user's interaction with the content", while the Receiver is an app "responsible for responding to Sender commands and for conveying streaming content from an online streaming service to the Cast-enabled device". The proof sits in a requirement in the media reference: "With adaptive bitrate streaming protocols, you must implement CORS." Cross-origin rules only bind a party making its own HTTP requests. The Chromecast, not the phone, is the client of the content server, which is also why the same page makes DRM the receiver's job, listing "Widevine (Level 1)" against both MPEG-DASH and HLS.

Google publishes the consequences itself, comparing a Cast-enabled site against casting a Chrome tab. Cast-enabled sites "can serve high quality content that is best for viewing on TV", which "often means you'll get a full 1080p high definition picture" and sometimes "5.1 surround sound (if supported by your TV or receiver)". Cast a tab instead and "you are limited to a maximum of 720p (if supported by your computer)". On load: Cast-enabled sites "play directly on Google streaming devices and put no load on your computer", whereas casting a tab "requires a lot of your computer's power, which is why it's not supported on all computers". On mobility: "When you play from a Cast-enabled site, you can shut down your computer or close the lid. With tab projection, you need to keep your computer on throughout the cast." The YouTube page puts it plainly: "You can continue to use your mobile device to perform other tasks while your video plays on your Chromecast."

Better picture, no battery cost, sender free to leave, all of it stated by the vendor.

Mirroring: the phone is a video encoder

Miracast is where the other model is written down most plainly. The Miracast Specification v2.3 (Wi-Fi Alliance, revision date 27 June 2024; version 1.0 was published 24 August 2012) makes "Encode and packetization of the captured Display" a mandatory function of a source and no part of a sink at all. Its data plane is "MPEG2-TS over RTP/UDP/IP", its control plane "RTSP over TCP/IP", and "A WFD Device shall use H.264" as the video codec, with a mandatory floor of 640x480 at 60 Hz in Constrained Baseline Profile level 3.1.

So a mirroring source keeps a hardware encoder running for the whole session, and every frame is handled twice: decoded on the phone, then re-encoded for the link. Apple describes the same split without the protocol detail, defining mirrored content as "content that's on the device, or live streams of what's happening on the device screen", and separating the AirPlay button inside a video app from the Screen Mirroring control in the system menu.

Handoff path versus mirroring path Two lanes. In the handoff lane the phone sends only a URL and control messages to the television, which then opens its own connection to the content server, so the phone stays idle and can leave. In the mirroring lane the video reaches the phone first, is decoded and re-encoded there, and the encoded screen is sent to the television, so the phone must stay in range with its encoder running. Handoff: the TV is the client Mirroring: the phone is the encoder Phone Television Content server URL and control request video no decode, no encode free to leave the room up to 1080p 5.1 audio possible Content server Phone Television video encoded screen decode, then re-encode encoder runs all session 720p ceiling for a Chrome tab
The handoff path leaves the phone idle while the television fetches the stream, and the mirroring path routes every frame through the phone's encoder.

Five names, two mechanisms

ProtocolWhat crosses to the TVDiscoverySpecification status
Google CastURL plus control messagesmDNS, _googlecast._tcpProprietary SDK, registered app ID
AirPlay videoMedia plus control messagesBonjour, plus BTLE and peer to peerProprietary, AirPlay audio licensed via MFi
AirPlay Screen MirroringEncoded screenSame as AirPlay videoProprietary
Matter CastingLaunchURL commandDNS-SDPublished by CSA, Apache 2.0 SDK
DLNA over UPnP AVURI handed to the rendererSSDP, 239.255.255.250:1900Published UPnP Device Architecture
MiracastEncoded screen, MPEG2-TSWi-Fi Direct or TDLS, no AP requiredWi-Fi Alliance document, marked proprietary

Four of the six hand over a pointer. Two send pixels. Grouping them by vendor, the usual way these get compared, hides the only distinction that predicts behaviour.

Open specification, published document, or neither

Matter Casting is the open one, and the least deployed. Amazon's implementation notes say "Fire TV and Echo devices implement Matter Casting as defined in the Matter specification 1.5", published by the Connectivity Standards Alliance, whose specification downloads run to Matter 1.6 as of June 2026. The reference implementation is public: the connectedhomeip repository calls Matter "a royalty-free connectivity standard", released "under the Apache 2.0 license". The mechanism is a handoff by design, since a client sends a "LaunchURL command (part of the Content Launcher cluster)" to the player.

UPnP, which DLNA packaged into interoperability guidelines, has a published architecture document, and the guidelines themselves stopped moving: DLNA announced its dissolution on 5 January 2017, and from 1 February 2017 SpireSpark International took over certification "to any company, with no membership fees required".

Google Cast and AirPlay publish SDKs, not protocols. Cast receivers "are registered using a distinct app ID, which is used to 'key' the corresponding Sender apps to that Receiver", registration runs through Google's developer console behind a "$5 developer account registration fee", and even a physical Chromecast must be registered before it will run your receiver. On Apple's side, AirPlay audio is one of the technologies in the MFi Program, which covers "third-party hardware accessories that use Apple's MFi licensed technology to connect electronically to Apple devices". Neither on-the-wire protocol is a document you can implement from.

Discovery is where casting actually breaks

Every one of these except Miracast finds its target with multicast service discovery, and multicast is exactly what a segmented network stops.

RFC 6762 (February 2013) is blunt about scope: "any fully qualified name ending in '.local.' is link-local, and names within this domain are meaningful only on the link where they originate", and "Any DNS query for a name ending with '.local.' MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB)", from UDP source port 5353. That address is inside the range RFC 5771 (March 2010) calls the Local Network Control Block, 224.0.0.0 to 224.0.0.255, whose addresses "are used for protocol control traffic that is not forwarded off link". Section 11 adds a second lock: responses "SHOULD be sent with IP TTL set to 255" so a querier can tell a packet came from the local link, and a host "MUST only accept responses to that query that originate from the local link". RFC 6763 supplies the naming above it, with a Service Instance Name of the form <Instance> . <Service> . <Domain>, which is why the service types are strings like _googlecast._tcp and, per Apple's deployment guide, _airplay._tcp and _raop._tcp.

Apple states the operational result directly: "Because multicast traffic is usually not routed across subnets, it requires Apple TV devices and AirPrint printers to be on the same IP subnet as the iPhone, iPad, and Mac devices that use them." Phone on the IoT VLAN, TV on the trusted one, and the device list stays empty no matter how healthy both connections are.

How far each discovery mechanism reaches Three discovery mechanisms drawn against a router boundary. Multicast DNS, used by Google Cast and AirPlay, sends to 224.0.0.251 on UDP port 5353, an address inside the block reserved for traffic that is not forwarded off link, so its reach stops at the first router. SSDP, used by UPnP and DLNA, sends to 239.255.255.250 on port 1900 with a default time to live of 2, so it can cross one router hop and remain visible on the far side. Miracast builds its own layer 2 link over Wi-Fi Direct and never uses the network at all, which is why it works without Wi-Fi and also why it cannot reach a television through your access points. your subnet next subnet or VLAN router mDNS, Cast and AirPlay 224.0.0.251, UDP 5353, link-local, stops here device list stays empty on the far side SSDP, UPnP and DLNA 239.255.255.250, port 1900, default TTL 2, crosses one hop still reachable Miracast, Wi-Fi Direct own layer 2 link, no network direct to the display, around the router entirely 224.0.0.0 to 224.0.0.255 is the Local Network Control Block, used for control traffic that is not forwarded off link. A DLNA server can therefore answer one hop away on a network where Cast and AirPlay are invisible. Same cable, different scope.
Link-local discovery stops at the router, SSDP gets one hop of reach, and Wi-Fi Direct never touches the network at all.

SSDP behaves differently, and this is worth knowing before blaming the wrong layer. UPnP Device Architecture 2.0 sends discovery to 239.255.255.250:1900 and says "the time-to-live (TTL) of each IP packet for each multicast message should default to 2 and should be configurable", noting that "When the TTL is greater than 1, it is possible for multicast messages to traverse multiple routers". A DLNA server can therefore be reachable one router hop away on a network where Cast and AirPlay are invisible.

Miracast sidesteps the question. It builds its own layer-2 link over Wi-Fi Direct or TDLS and works, in the Wi-Fi Alliance's phrasing, "even if a Wi-Fi network is not available". That independence is also why it cannot reach a TV through your access points.

Client isolation on a guest SSID kills it

The guest network setting people reach for is the one that guarantees failure. Cisco Meraki's definition is representative: "Wireless Client Isolation is a security feature that prevents wireless clients from communicating with one another", useful "for guest and BYOD SSIDs", and with it enabled "clients will only be able to communicate with the default gateway and will not be able to communicate with any other devices on the same VLAN (or broadcast domain)". Discovery packets and the media session are both client-to-client traffic, so both die.

Vendors work around it rather than fix it. Meraki's firmware permits up to 16 MAC addresses as exceptions to the layer 2 isolation, and the ones to add are the multicast MACs behind mDNS, "01:00:5E:00:00:FB" for IPv4 and "33:33:00:00:00:FB" for IPv6. Bonjour forwarding is the other route, a gateway that relays announcements between VLANs, which Apple anticipates: networks using such features "should be configured to advertise both _airplay._tcp and _raop._tcp services".

Google removed its own escape hatch. Guest mode let visitors cast "without connecting to your Wi-Fi network" using a PIN; the support page now reads "Guest mode is no longer supported. Guests can cast content from their Android or iOS devices by connecting to the host's Wi-Fi network."

The DRM reason an app will not mirror

A protected stream reaching the TV by handoff is decrypted there, inside whatever secure path that device holds. Mirroring asks for the opposite: decrypt on the phone, then re-encode the decrypted pixels and transmit them. Every content protection scheme treats that as the thing it exists to prevent.

Android exposes the switch directly. "FLAG_SECURE is a Window flag that tells Android not to allow screenshots or to display the window view on a non-secure display (such as Casting the screen)", and Android "prevents the window from being displayed on a non-secure display, such as a TV or projector". An app sets one flag and its window goes black on the mirrored output. Google's own caveat is that enforcement was uneven historically: "For Android 11 (API 30) and lower FLAG_SECURE is able to help around 70% of the devices reliably."

Miracast encodes the same rule into the specification. Link Content Protection, its HDCP 2.x layer, is an optional feature for both source and sink, with a note attached: "If Link Content Protection is not supported either by the WFD Source or the WFD Sink, protected content shall not be streamed." A black rectangle where the video should be is the protocol working as written.

Why a protected title casts but will not mirror Two paths for the same protected video. On the handoff path the phone sends only a pointer, the television fetches the stream itself and decrypts it inside its own protected path, and the title plays. On the mirroring path the phone must decrypt the video and then re-encode the decrypted pixels for transmission, which is the thing content protection exists to prevent. Android blocks it at the window flag FLAG_SECURE, which stops the window appearing on a non-secure display, and Miracast blocks it at the Link Content Protection check, whose specification states that protected content shall not be streamed if that layer is unsupported. The result is a black rectangle rather than a network fault. handoff path phone sends a pointer only TV fetches stream decrypts on the TV plays decryption never leaves the television's protected path mirroring path phone decrypts then re-encodes FLAG_SECURE window blocked Link Content Protection absent, so refused black frame Two independent blocks on one path. Either is enough, which is why no router setting moves this. Miracast: if Link Content Protection is unsupported at either end, protected content shall not be streamed. Enforcement was uneven historically. Google puts FLAG_SECURE at around 70% of devices on Android 11 and lower. A title that plays under a Cast button and blanks under screen mirroring is content protection, not bandwidth.
A protected title plays over the handoff path and is refused on the mirroring path, at the window flag and at the link protection check.

What to check, in order

Look at which control you pressed. A Cast or AirPlay button inside the video player is a handoff; the mirroring toggle in a system menu or quick settings is an encoder. A hot phone and a soft picture mean you are mirroring something that could have been handed over.

If nothing appears in the device list, the fault is discovery, not the media path. Put both devices on the same subnet first, then check for client isolation on that SSID, then for an mDNS gateway if the two must live on different VLANs. Apple's own troubleshooting starts in the same place, asking you to "Check that the devices are updated to the latest software and are on the same Wi-Fi network."

If discovery works and playback does not, look for content protection rather than bandwidth. A stream that plays over a Cast button and blanks under screen mirroring is not a network problem, and no router setting will move it.

Sources