airplay协议简述
Airplay协议总结：
Airplay可以将iPhone,iPad或iPodtouch等设备上的视频、音频以及图片传输到第三方认证设备上，一般是在AppleTV或Air port设备上，但其实，现在很多第三方的android设备也可以支持Airplay了，像阿里云或小米的盒子都支持Airplay投影了，而且效果都还不错。
其实，Airplay算是苹果公司定义的一种协议，或是一种技术吧，所以，按照惯例，这项技术是不开源的，对外封闭。而Android端，可以使用一套的多屏互动方案的，叫做DLAN，即Digital Living Network Alliance，它的协议是公开的。再次，得感谢诸多技术大牛，破解了Airplay，包括音频投影服务中使用的RSA私钥， 和一份具体的协议说明：airplay文档
相关资料：
DroidAirPlay
PC端项目AirReceiver
Android项目AndroidAirPlayReceiver
DroidAirplay问题完善
通讯文档
大神的研究
下面，就Airplay协议内容大概的说明一下
1.使用multicastDNS协议来进行服务发现，在android端可以用JmDNS来实现。
一般我们会发布两个服务：AirTunes service（RAOP）和AirPlay Service，前者用于音频流的投影，后者用于图片和视频内容的投影。
2.协议内容（一）：AirTunesService
2.1.协议中的音频流支持RTSP协议。
1）IOS设备向服务端发送的RTSP请求包括
ANNOUNCE：告诉RTSP服务器关于流的各种属性
SETUP：告诉RTSP服务器初始化一个record session，同时通知必要的传输信息。
RECORD：请求服务器开始流的传输
FLUSH：请求停止传输
TEARDOWN：请求结束RTSP会话
PAUSE,
OPTIONS,
GET_PARAMETER,
SET_PARAMETER：可用于音量控制，Metadata：其中包括音频曲名，歌手名，专辑名，封面图片，播放进度信息……
POST and GET
2）RTP流，用于传输音频数据等。（如果说，RTSP用于发起/终结流媒体，那么RTP则传输流媒体数据 ）
这里音频包是几乎完全兼容RTP协议。RTP包按有效载荷的不同类型分为以下几种：
Audio packets：其有效载荷为经过加密的audio data
Sync packets：服务端每秒钟会收到一个同步包，来将RTP中的timestamps与用于始终同步的NTP time关联起来
Retransmit packets:对丢失的audio packets进行重传
Timing packets:用于音频的主时钟同步
2.2音频数据加密解密
Client：客户端首先会用RSA公钥，利用OAEP加密方式自动生成一个随机的128位AES key，然后和rsaaes key，aesiv一起发送给Server。
Sever：服务端利用指定的RSA私钥来解密AES key，然后将解密结果返回给Client。
Client：客户端利用RSA公钥要解密收到的数据，若解密结果和之前自动生成的随机数一致，则表明服务端解密成功。
1、RSA密钥传递音频流加密密钥：
发送端：RSA公钥加密AES密钥，HTTP发送
播放端：RSA私钥解密AES密钥，保存
2、播放音频流：
发送端：AES加密音频流，rtsp推送
播放端：AES密钥解密音频流，播放
3、RSA私钥：
#defineAIRPORT_PRIVATE_KEY \
"-----BEGIN RSAPRIVATE KEY-----\n" \
"MIIEpQIBAAKCAQEA59dE8qLieItsH1WgjrcFRKj6eUWqi+bGLOX1HL3U3GhC/j0Qg90u3sG/1CUt\n"\
"wC5vOYvfDmFI6oSFXi5ELabWJmT2dKHzBJKa3k9ok+8t9ucRqMd6DZHJ2YCCLlDRKSKv6kDqnw4U\n"\
"wPdpOMXziC/AMj3Z/lUVX1G7WSHCAWKf1zNS1eLvqr+boEjXuBOitnZ/bDzPHrTOZz0Dew0uowxf\n"\
"/+sG+NCK3eQJVxqcaJ/vEHKIVd2M+5qL71yJQ+87X6oV3eaYvt3zWZYD6z5vYTcrtij2VZ9Zmni/\n"\
"UAaHqn9JdsBWLUEpVviYnhimNVvYFZeCXg/IdTQ+x4IRdiXNv5hEewIDAQABAoIBAQDl8Axy9XfW\n"\
"BLmkzkEiqoSwF0PsmVrPzH9KsnwLGH+QZlvjWd8SWYGN7u1507HvhF5N3drJoVU3O14nDY4TFQAa\n"\
"LlJ9VM35AApXaLyY1ERrN7u9ALKd2LUwYhM7Km539O4yUFYikE2nIPscEsA5ltpxOgUGCY7b7ez5\n"\
"NtD6nL1ZKauw7aNXmVAvmJTcuPxWmoktF3gDJKK2wxZuNGcJE0uFQEG4Z3BrWP7yoNuSK3dii2jm\n"\
"lpPHr0O/KnPQtzI3eguhe0TwUem/eYSdyzMyVx/YpwkzwtYL3sR5k0o9rKQLtvLzfAqdBxBurciz\n"\
"aaA/L0HIgAmOit1GJA2saMxTVPNhAoGBAPfgv1oeZxgxmotiCcMXFEQEWflzhWYTsXrhUIuz5jFu\n"\
"a39GLS99ZEErhLdrwj8rDDViRVJ5skOp9zFvlYAHs0xh92ji1E7V/ysnKBfsMrPkk5KSKPrnjndM\n"\
"oPdevWnVkgJ5jxFuNgxkOLMuG9i53B4yMvDTCRiIPMQ++N2iLDaRAoGBAO9v//mU8eVkQaoANf0Z\n"\
"oMjW8CN4xwWA2cSEIHkd9AfFkftuv8oyLDCG3ZAf0vrhrrtkrfa7ef+AUb69DNggq4mHQAYBp7L+\n"\
"k5DKzJrKuO0r+R0YbY9pZD1+/g9dVt91d6LQNepUE/yY2PP5CNoFmjedpLHMOPFdVgqDzDFxU8hL\n"\
"AoGBANDrr7xAJbqBjHVwIzQ4To9pb4BNeqDndk5Qe7fT3+/H1njGaC0/rXE0Qb7q5ySgnsCb3DvA\n"\
"cJyRM9SJ7OKlGt0FMSdJD5KG0XPIpAVNwgpXXH5MDJg09KHeh0kXo+QA6viFBi21y340NonnEfdf\n"\
"54PX4ZGS/Xac1UK+pLkBB+zRAoGAf0AY3H3qKS2lMEI4bzEFoHeK3G895pDaK3TFBVmD7fV0Zhov\n"\
"17fegFPMwOII8MisYm9ZfT2Z0s5Ro3s5rkt+nvLAdfC/PYPKzTLalpGSwomSNYJcB9HNMlmhkGzc\n"\
"1JnLYT4iyUyx6pcZBmCd8bD0iwY/FzcgNDaUmbX9+XDvRA0CgYEAkE7pIPlE71qvfJQgoA9em0gI\n"\
"LAuE4Pu13aKiJnfft7hIjbK+5kyb3TysZvoyDnb3HOKvInK7vXbKuU4ISgxB2bB3HcYzQMGsz1qJ\n"\
"2gG0N5hvJpzwwhbhXqFKA4zaaSrw622wDniAK5MlIE0tIAKKP4yxNGjoD2QYjhBGuhvkWKaXTyY=\n"\
"-----END RSAPRIVATE KEY-----"
PEM-encodedPKCS#8格式的私钥：
/**
* The AirTunes private key in PEM-encoded PKCS#8 format.
* Original Key from shairport was in PEM-encoded PKCS#1 format
*/
private static final String PrivateKeyData =
"MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDn10TyouJ4i2wf\n" +
"VaCOtwVEqPp5RaqL5sYs5fUcvdTcaEL+PRCD3S7ewb/UJS3ALm85i98OYUjqhIVe\n" +
"LkQtptYmZPZ0ofMEkpreT2iT7y325xGox3oNkcnZgIIuUNEpIq/qQOqfDhTA92k4\n" +
"xfOIL8AyPdn+VRVfUbtZIcIBYp/XM1LV4u+qv5ugSNe4E6K2dn9sPM8etM5nPQN7\n" +
"DS6jDF//6wb40Ird5AlXGpxon+8QcohV3Yz7movvXIlD7ztfqhXd5pi+3fNZlgPr\n" +
"Pm9hNyu2KPZVn1maeL9QBoeqf0l2wFYtQSlW+JieGKY1W9gVl4JeD8h1ND7HghF2\n" +
"Jc2/mER7AgMBAAECggEBAOXwDHL1d9YEuaTOQSKqhLAXQ+yZWs/Mf0qyfAsYf5Bm\n" +
"W+NZ3xJZgY3u7XnTse+EXk3d2smhVTc7XicNjhMVABouUn1UzfkACldovJjURGs3\n" +
"u70Asp3YtTBiEzsqbnf07jJQViKQTacg+xwSwDmW2nE6BQYJjtvt7Pk20PqcvVkp\n" +
"q7Dto1eZUC+YlNy4/FaaiS0XeAMkorbDFm40ZwkTS4VAQbhncGtY/vKg25Ird2KL\n" +
"aOaWk8evQ78qc9C3Mjd6C6F7RPBR6b95hJ3LMzJXH9inCTPC1gvexHmTSj2spAu2\n" +
"8vN8Cp0HEG6tyLNpoD8vQciACY6K3UYkDaxozFNU82ECgYEA9+C/Wh5nGDGai2IJ\n" +
"wxcURARZ+XOFZhOxeuFQi7PmMW5rf0YtL31kQSuEt2vCPysMNWJFUnmyQ6n3MW+V\n" +
"gAezTGH3aOLUTtX/KycoF+wys+STkpIo+ueOd0yg9169adWSAnmPEW42DGQ4sy4b\n" +
"2LncHjIy8NMJGIg8xD743aIsNpECgYEA72//+ZTx5WRBqgA1/RmgyNbwI3jHBYDZ\n" +
"xIQgeR30B8WR+26/yjIsMIbdkB/S+uGuu2St9rt5/4BRvr0M2CCriYdABgGnsv6T\n" +
"kMrMmsq47Sv5HRhtj2lkPX7+D11W33V3otA16lQT/JjY8/kI2gWaN52kscw48V1W\n" +
"CoPMMXFTyEsCgYEA0OuvvEAluoGMdXAjNDhOj2lvgE16oOd2TlB7t9Pf78fWeMZo\n" +
"LT+tcTRBvurnJKCewJvcO8BwnJEz1Ins4qUa3QUxJ0kPkobRc8ikBU3CCldcfkwM\n" +
"mDT0od6HSRej5ADq+IUGLbXLfjQ2iecR91/ng9fhkZL9dpzVQr6kuQEH7NECgYB/\n" +
"QBjcfeopLaUwQjhvMQWgd4rcbz3mkNordMUFWYPt9XRmGi/Xt96AU8zA4gjwyKxi\n" +
"b1l9PZnSzlGjezmuS36e8sB18L89g8rNMtqWkZLCiZI1glwH0c0yWaGQbNzUmcth\n" +
"PiLJTLHqlxkGYJ3xsPSLBj8XNyA0NpSZtf35cO9EDQKBgQCQTukg+UTvWq98lCCg\n" +
"D16bSAgsC4Tg+7XdoqImd9+3uEiNsr7mTJvdPKxm+jIOdvcc4q8icru9dsq5TghK\n" +
"DEHZsHcdxjNAwazPWonaAbQ3mG8mnPDCFuFeoUoDjNppKvDrbbAOeIArkyUgTS0g\n" +
"Aoo/jLE0aOgPZBiOEEa6G+RYpg==\n" +
"";3.协议内容（二）：AirPlay Service
/reverse
协商请求
/scrub
POST方式为seek请求
GET方式为获取播放位置
/volume
设置音量：0.000000为静音，1.000000为最大
/play
播放请求：携带播放链接
本地文件播放为http，网络文件播放为m3u8地址
/rate
播放与暂停：0.000000为暂停，1.000000为播放
/stop
停止播放
/photo
推送图片：在HTTP的Body发送实际图片
/playback-info
获取播放端的状态：总时长、缓冲时长、播放位置、播放器状态（LOADING、PLAYING、PAUSED、STOP）等信息
/server-info
获取服务器信息：主要是mac地址信息Airplay Mirroring客户端的同屏交互过程，分为三个主要步骤：
1. 设备广播与发现
2. 信息交互与能力协商
3. 音视频数据接收与解密
设备广播与发现
Airplay设备间的广播与发现通过Bonjour协议进行。Bonjour也被称为ZeroConf, mDNS等，可以用来在局域网内进行数据记录广播与发现。该协议比较成熟，网上可以找到诸多介绍。对于实现的Airplay（包括Mirroring）接收端而言，首先需要注册两类服务，即airtunes和airplay。 Airtunes服务主要用来处理广播视音频接收能力协商，是最为重要的服务内容，对应Bonjour记录名称为'_raop._tcp'，注册服务端口不限，一般为了避免冲突，建议采用较高的端口数；Airplay服务主要用来兼容传统的streaming等服务，对应记录名称为'_airplay._tcp'，注册端口一般为7000。
具体的服务广播内容，可以进行局域网抓包，找到对应记录内容。
当接收端通过Bonjour广播器服务能力后，发送端（如iPhone等各类iOS设备）就可以发现该接收端。
信息交互与能力协商
当发送端发现接收端后，可以开始信息交互与能力协商过程。该部分协议协议格式类似rtsp协议格式。主要分为两个阶段，设备匹配与和能力协商。
当发送端链接服务端后，设备匹配过程即开始。通信双方会进行fairplay加密协议进行信息交换，当完成信息交换后，客户端后续必须使用这部分信息来处理加密过的密钥，才能获得进一步视音频解密密钥。在iOS9之后，在fairplay过程之前，增加一个设备匹配过程，即pair-setup、pair-verify过程，其主要算法是较为标准的非对称公钥交换算法。
当两端成功匹配后，开始进行能力协商与信息交换，这些信息包括，设备名称、代号，音视频接收相关端口配置，视频接收能力以及加密密钥等，相关信息使用binary plist格式进行封装。
可以参考python版Slave-in-the-Magic-Mirror
音视频数据接收与解密
双方协商成功后，发送端开始向接收端发送视音频数据，mirroring数据是通过TCP进行发送，为h.264 ES流格式。音频是通过RTP协议进行发送，根据内容的不同音频编码为ALAC或者AAC-ELD。
音视频流都是通过AES进行了加密处理，密钥需要通过上面一步的进过信息交互后的fairplay模组对setup过程中接收到的加密密钥进行解密，获得的AES解密需要的IV和KEY，然后经过AES解扰，即可以获得最终的音视频流。
其他需要注意的地方
Airplay没过Session传送过来的视频h264码流，只有开头一个关键帧. 因此这种情况并不适合直播这种需要固定GOP的场景. 还需要做进一步的转码的工作，或者直接在压缩域进行处理，获得合理的GOP结构。