Airplay and (Relay) Remotes

What do you need help with?

Tja @postlund ! I’m working on the OpenAirplay AP2 receiver , and trying to figure out a few details of how Remotes work just for Airplay (audio). We don’t use pyatv… yet. It would probably work, but seems like a sledgehammer to crack a nut.

I’ve got HK implemented, and threading working, so iPhones can independently change properties of an active AP2 receiver.

Something like this happens:

Device 1 connects, and sends its groupUUID, which the receiver ZeroConf broadcasts. Then all the flies come for the shit banquet 😈

The gid flag present in mDNS is what triggers other devices to present the “Control Other TVs & Devices” in e.g. Music app as long as the receiver broadcasts flag bit 17 for RelayRemote. The other devices connect, present a type 130 stream, and poll the receiver for what’s going on. And differing somewhat from your description in the docs, they connect to the dataPort, but never do anything more, similar to how you describe the eventPort - nothing happens there. I tried passing it to a HAPSocket and encrypting with the Events-Salt etc you wrote about. Maybe I’m missing some special sauce there, but the senders don’t send seed or other keys like your docs mention. It does RECORD, then on SETUP they send e.g.:

{'streams': [{'channelID': 'DF40296C-7924-42EE-B401-FB209A52EAEA', 'clientTypeUUID': '1910A70F-DBC0-4242-AF95-115DB30604E1', 'clientUUID': '2476F28A-BF17-4631-B267-A9482E892402', 'controlType': 1, 'type': 130}]}

They use controlType 1 because I broadcast the stats flag RemoteControlRelay = 1 << 11. Type 2 is Direct, I think.

So at this point, Remote devices connect via HK pairings, poll, and disconnect after three ‘attempts’ to do what they try to do, either triggered via the Music app, or via HomeKit. But no device tries to encrypt the dataPort or connect to anything else. Am I missing something or is everything like this on iOS <= 15? It feels like I have not yet added something necessary in a response to SETUP or RECORD (but those exchanges look largely as written in your docs).

Do you have any pointers, or ideas what’s going on here? This is AP2 for audio specifically. But the underlying details should be the same…

If it’s any consolation, I get the same behaviour with Sonos speakers. 🤷‍♂️ Maybe it really is supposed to be like this, but that’s a bit shit.

[postlund]

You basically want to implement the MRP service in my fake device, which is available here:

https://github.com/postlund/pyatv/blob/master/tests/fake_device/mrp.py

It is extremely hacky and specific to test pyatv. It is also not compatible with iOS as-is as I haven’t made any integration towards iOS. So you need to make adjustments.

You don’t need all dependencies, but the protobuf messages are necessary. Ideally those should be a separate python package, but I haven’t seen any need for that so far so didn’t put any time into that. You will have to copy them I guess.

[postlund]

wantsDedicatedSocket must be present (and set to True) is… not always true for me. In fact, I never see wantsDedicatedSocket. I wonder whether you could test for me: you have an iPhone and a receiver which both support AP2? Seeing what differences you get could be interesting. You can try my dev branch (run it with e.g. python3 ap2-receiver.py -n en0 --debug to see whether you get the same results when you:

• add the receiver in HK
• cast to it via AP, and
• try to remote control it from HK from a separate device (tho your main iPhone might also try to set up an RC session)

I believe this to be an Apple-specific setting that is not part of the general AirPlay 2 specification, but I can of course be wrong. There is likely a flag that indicates if this kind of remote is possible to set up, but I’m not sure. Did you try to replicate the feature flags of a HomePod for instance to see how iOS behaves? My HomePod announces 0x4A7FCA00,0xBC354BD0 as a reference.

I respond with a dynamic dataPort, but nothing yet is ever set up. I wonder whether it falls back to one of the older static ports, but captures don’t seem to indicate anything like that. Maybe I missed something.

Hard to tell, I don’t have any ideas I’m afraid.

Do you know the proper way to distinguish an AirPlay v1 receiver from an AirPlay v2 receiver?

Hmm - the best way for receivers, I think, is certain bit-flags. PTP is the big one: airplay 2 mandates it. Everything before then is NTP (bit-flag 45). So if the PTP bit-flag 41 is off, it’s likely not AP2. If I turn off PTP, all clients try AP1 ANNOUNCE method. On, and they don’t. Those bit-flags are usually mutex, but it’s possible to enable both and advertise support for older and newer clients. There are other more subtle tests like:

• RTSP port numbers (7000 for AP2)
• whether all of the mDNS flags are RAOP, and two characters “XX”
• Probably also HK pairing support - bit-flag 46 and 48
• You might also want to look out for the marketing version string version and SDK version sdk which are sometimes advertised.

Ok, great. You haven’t found any obvious way either 😉 I believe that is good enough for my filtering at least. Thanks!