airplay2协议介绍

RTSP

Overview

The AirPlay 2 sender communicates with receivers through the RTSP protocol defined in RFC2326. However, Apple RTSP implementation has been customized to behave similarly to both an RTSP and a HTTP server.

The request-URI ends with RTSP/1.0 e.g. GET /info RTSP/1.0.

An RTSP HTTP-like request can have the following headers:

GET /info RTSP/1.0
X-Apple-ProtocolVersion: 1
Content-Length: 70
Content-Type: application/x-apple-binary-plist
CSeq: 0
DACP-ID: 93842EE68464F5B9
Active-Remote: 1149412352
User-Agent: AirPlay/409.16

Instead, a standard RTSP request can have the following headers:

SETUP rtsp://192.168.1.12/15566703517752576217 RTSP/1.0
Content-Length: 819
Content-Type: application/x-apple-binary-plist
CSeq: 1
DACP-ID: 93842EE68464F5B9
Active-Remote: 1149412352
User-Agent: AirPlay/409.16

RTSP headers

HeaderDescription
X-Apple-ProtocolVersionProtocol version
Content-LengthLength of the content/body after the headers
Content-TypeType of content
CSeqSpecifies the sequence number for an RTSP request/response pair. Receiver must reply with the same CSeq. Incremented by one in every request.
DACP-ID64-bit value identifying the DACP server (remote control of the sender)
Active-RemoteAuthentication token for the DACP server (remote control of the sender)
RTP-InfoSent with FLUSH for RTP synchronization

RTSP requests

The receiver must implement the endpoints reported in the following subsections. Their behavior could be different depending on the content type.

GET /info

Sender needs info from the receiver

Content-type: application/x-apple-binary-plist

The sender asks for specific info. The request body is encoded in a binary plist. Usually the sender initiates the communication demanding the txtAirPlay  qualifier of the receiver with the following binary plist:

{'qualifier': ['txtAirPlay']}

This requests actually asks the TXT record of the _airplay._tcp mDNS service as a binary plist. This also suggests that a receiver can have a minimal TXT mDNS record and then declare further information at this stage.

 

Example

server -> client↕

client -> server↕

 

No content type

The server sends a second /info request to ask for additional information. The request has no body. The receiver replies with a binary plist which may contain the following key:value entries:

KeyTypeDescription
initialVolumeIntegerA value from -144 to 0 corresponding to the initial volume of the receiver [dB]

 

Example

server -> client↕

 

client -> server↕

POST /auth-setup

 

Example

server -> client↕

client -> server↕

 

POST /fp-setup

 

Example

server -> client↕

client -> server↕

 

POST /pair-setup

 

Example

server -> client↕

client -> server↕

 

POST /pair-verify

 

Example

server -> client↕

client -> server↕

 

POST /command

 

Example

server -> client↕

client -> server↕

 

POST /feedback

Probably an heartbeat to ensure the ensure the receiver is alive. Sent until the receiver is disconnected.

 

Example

server -> client↕

client -> server↕

 

POST /audioMode

 

Example

server -> client↕

client -> server↕

 

SETUP

This is the setup request used to establish the communication with the receiver and configure the timeeventcontrol and data channels between the two. The time channel is used only with NTP synchronization and stays down when using PTP.

1) SETUP info and event

The sender communicate generic info about the device, timing protocol, timing peers and values related to encryption: ekeyeiv and et (encryption type). timingPeerInfo and timingPeerList are needed if receiver supports PTP and the sender announces timingProtocol=PTP.

The receiver sets up an event channel (TCP) and communicates the port, together with its timing info. If the receiver declares PTP time synchronization, then timingPort won't be used. If sender and receiver use NTP instead, the receiver must open a timing channel and declare its port into timingPort.

The event channel must be open or the RTSP won't continue.

 

Example

server -> client↕

client -> server↕

 

2) SETUP control and data

This SETUP requests is sent as soon as audio streaming must start. The sender declares audio format, latencies, its control port and the following parameters:

  • audioFormat - the audio format;
  • ct - compression type;
  • shk - shared encryption key;
  • spf - Frames per packet.

The key type is used to declare the type of streaming.

TypeDescription
96General audio - Real time
103General audio - Buffered
110Screen
120Playback
130Remote control

The key ct stands for compression type.

Compression typeDescription
1LPCM (Linear Pulse Code Modulation)
2ALAC (Apple Lossless)
4AAC (Advanced Audio Coding)
8AAC ELD (Enhanced Low Delay)
32OPUS1

The receiver prepares its control and data channels (UDP or TCP depending on the type) and communicates the respective ports in controlPort and dataPort. The control channel will receive RTCP2 packets while the data channel the actual streaming payload over RTP3.

The value of audioFormat is encoded as described in section Audio codecs

 

Example

server -> client↕

client -> server↕

 

SET_PARAMETER

Used to set parameters on the receiver end or to communicate something, depending on Content-Type.

Content-TypeBodyDescription
text/parameters"volume: N”Volume to set on the receiver
text/parameters"progress: X/Y/Z”Progress of the current track (start/current/end)
image/jpegdataJPEG image of the artwork
application/x-dmap-taggeddataNow playing info using DAAP

 

Example: volume

server -> client↕

client -> server↕

 

GET_PARAMETER

Get a parameter from the receiver.

 

Example: volume

server -> client↕

client -> server↕

 

SETPEERS

Used to communicate other possible receivers in the multi-room group. It is a binary plist containing a list of IPv4 and IPv6 addresses of the devices in the group.

 

Example: single receiver

server -> client↕

client -> server↕

 

 

Example: multi-group join

server -> client↕

client -> server↕

 

RECORD

The sender wants to start streaming.

 

Example

server -> client↕

client -> server↕

 

FLUSH

Sent every time the audio streaming is about to start. The RTSP request includes the header RTP-Info: seq=X;rtptime=YX is the first RTP sequence number and Y the first RTP timestamp.

 

Example

server -> client↕

client -> server↕

 

TEARDOWN

Sent when audio is paused or AirPlay is stopped. The body is a binary plist containing active streams, if audio is on pause, or empty if AirPlay is disconnected.

 

Example: Pause

server -> client↕

client -> server↕

 

 

Example: Disconnect

server -> client↕

client -> server↕

 


  1. Definition of the Opus Audio Codec - https://tools.ietf.org/html/rfc6716 ↩︎

  2. RTP: A Transport Protocol for Real-Time Applications - SR: Sender Report RTCP Packet - https://tools.ietf.org/html/rfc3550#section-6.4.1 ↩︎

  3. RTP: A Transport Protocol for Real-Time Applications - https://tools.ietf.org/html/rfc3550 ↩︎

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值