In my previous post, I explored how the cast device find and configure the Chromecast dongle. In this post, I'll dig into the actual cast process.
Cast Screen
When casting screen, the cast device (Nexus 6P in my case) basically need to send a serious of screen shots (probably 30 or 60 FPS) to the chromecast, which incurs high throughput demand (double the actualy throughput required) to the Wifi network if this traffic is routed by the AP, i.e., cast device -> AP -> Chromecast.
Standards such as Miracast exits for such purpose (HDMI over Wifi), but it requires a direct ad-hoc network between the two devices. While in the case of Chromecast, both the Nexus 6p and the Chromecast (at least the Nexus 6P) are still associated with the AP from my experience. So how does Chromecast do it?
I captured a packet trace while setting up a screen cast session, and find one interesting packet type that I was not aware of: TDLS, which is short for Tunneled Direct Link Setup protocol.
The setup packets are shown in the following screen shot.
The 80:13 device is my Nexus 6P, the e8:de device is the Wifi AP and the 6c:ad device is the Chromecast dongle. We can see that the Nexus 6P first negociate the TDLS parameters via the TDLS Discovery process, then a TDLS link is setup between the Nexus 6P and the Chromecast. It is confirmed that a direct traffic between the Nexus 6P and the Chromecast happened afterwards.
The same mechinism applies for casting a Chromium tab as well.
Cast YouTube
In another cast scenario, where the content is not originated from the cast device, but from some web server, as in YouTube, Netflix, etc. I did not observe a TDLS setup process, which makes sense since the content is not on the cast device, and the lightweight signaling packets (content URL, pause, volume) between the cast device and the Chromecast does not justify the overhead of setting up a TDLS link.