After a few tries, I got that working.
Then @ehorley asked whether it was using IPv6 or not, and the answer was more complicated than I expected: it uses IPv6 for session control, but IPv4 for actual streaming video. I don't know why.
The MacBook Air is hosting an ad-hoc wireless network "protected" by WEP, which is the only encryption available (thanks a lot, Apple). This is lousy security, but it means I don't get any other traffic to confuse the results.
I am connecting with an iPad Mini, and displaying live camera images from the iPad on the MacBook Air screen.
I captured the network traffic with Wireshark.
Here is the
PCAPNG file (24 MB).
Here are excerpts from the stream, showing that it set up sessions for both audio and video over IPv6:
ANNOUNCE rtsp://fe80::2acf:e9ff:fe4f:2b55/8449035571049553832 RTSP/1.0
X-Apple-Device-ID: 0xe48b7f644789
X-Apple-Client-Name: Sam's iPad Mini
SETUP rtsp://fe80::2acf:e9ff:fe4f:2b55/8449035571049553832/audio RTSP/1.0
Transport: RTP/AVP/UDP;unicast;mode=screen;timing_port=49234;events;control_port=54059;redundant=2
SETUP rtsp://fe80::2acf:e9ff:fe4f:2b55/8449035571049553832/video RTSP/1.0
TEARDOWN rtsp://fe80::2acf:e9ff:fe4f:2b55/8449035571049553832 RTSP/1.0
You can see the whole stream
here
.
As explained in the article referenced below, this runs over port 7100 on the server:
Unofficial AirPlay Protocol Specification
Even though the session was set up with IPv6 addresses, it actually runs over IPv4. I don't know why--my Mac is listening on port 7100 for both IPv4 and IPv6: