airplay协议简述

本文主要是介绍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协商请求/scrubPOST方式为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结构。

这篇关于airplay协议简述的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---