AirTunes 2 Protocol
Contents
Introduction
Airtunes 2 is the protocol used by Apple's Airport Express, iTunes and Rogue Amoeba's Airfoil. The previously known RAOP protocol does not support more advanced timing features, and as such, some software, such as PulseAudio do not support audio/video syncing and sometime suffer from unreliable playback. The Airtunes 2 project seeks to remedy this.
Conventions
In the examples below, values to be replaced are put into curly braces ("{}"). The braces should not be included after replacing the values.
Streaming audio to an AirTunes 2 compatible server
If encryption is necessary, a random key and IV (initialization vector) for AES encryption, 16 bytes each, should be generated.
Every stream has an associated RTP timestamp (uint32; initially set to a random number transmitted to the server in the RECORD RTSP request) and a sequence number (int16; initially set to random value transmitted to the server in the RECORD RTSP request). Both are updated when sending audio packets. Audio data is encapsulated in RTP packets which are sent sent as UDP packets to the audio port.
There are TIMESTAMPS_PER_SECOND RTP timestamp ticks per second (equivalent to the number of frames per second).
Up to PACKET_BACKLOG audio packets should be kept around after encoding and encryption to resend if necessary. After sending an audio packet, the sender should check if a sync packet should also be sent (basically every TIMESYNC_INTERVAL frames and just after connecting).
Connect
- Establish TCP connection to RTSP port
- IP address(es) from Zeroconf TXT record
- Send RTSP OPTIONS request
- Send RTSP ANNOUNCE request
- Use password authentication based on authentication type from Zeroconf TXT record or after receiving HTTP status code 401 (401 Unauthorized)
- Send RTSP SETUP request
- Set sequence number of connection to a random 16 bit unsigned int and initial RTP timestamp to a random 32 bit unsigned int. Normal play time (npt) is initially 0.
- Send RTSP RECORD request
- Send RTSP SET_PARAMETER request to set initial volume (see Setting volume)
- Prepare RTP connection for audio packets
Transmitting Audio
The audio data is encapsulated in an RTP packet (see RFC3550 Section 5.1)
- Bytes 0-1 of the RTP Header are 0x80, 0x60 (0x80, 0xe0 for the 1st packet in a stream or after a FLUSH).
- Bytes 2-3 store the current sequence number (whose initial value was set in the RECORD RTSP request)
- Bytes 4-7 store the current RTP timestamp (initial value was transmitted to the Airtunes device in the RECORD RTSP request)
- Bytes 8-11 store the SSRC (random number which will be the same in all audio packets, see RFC3550 Section 5.1 for more details) (TODO: is the SSRC the same as the RTSP client session ID ?)
- Starting at byte 12 comes the audio data (see Packetizing audio for its format)
- Send this RTP packet as UDP on the audio data port
- Increase sequence number by one for next audio packet
- Increase timestamp by number of frames in this audio packet
Suspending Audio Transmission
- Send a FLUSH RTSP request
- Stop sending audio packets
- If the audio transmission is suspsending for too long (iTunes defines "too long" as being equal to 2 seconds), send an RTSP TEARDOWN request.
Resuming Audio Transmission
- If a TEARDOWN request has been sent, the RTSP connection has to be recreated, so the steps described in Connect have to be replayed (the OPTIONS step can be omitted)
- Start sending audio as if it was a new audio stream even if the Connect steps weren't replayed. This means the transmission will start with a SyncPacket marked as a "first" packet, and it will be followed by an Audio packet with the "first" marker too.
Disconnect
- Stop sending audio data
- Close RTSP connection
Preferred TCP/UDP ports
Connection | Port |
---|---|
RTSP | 5000 |
Audio data | 6000 |
RTP control | 6001 |
Timing | 6002 |
Payload types
Timing request | 0x52 |
Timing response | 0x53 |
Sync | 0x54 |
Range resend | 0x55 |
Audio data | 0x60 |
Data types
When transferred over the network, multi-byte values need to converted to network byte order. No aligning must be used within the packet structures.
RtpHeader
/* RTP header bits */ RTP_HEADER_A_EXTENSION = 0x10; RTP_HEADER_A_SOURCE = 0x0f; RTP_HEADER_B_PAYLOAD_TYPE = 0x7f; RTP_HEADER_B_MARKER = 0x80; /* sizeof(RtpHeader) == 4 */ RtpHeader { uint8_t a; uint8_t b; uint16_t seqnum; /* extension = bool(a & RTP_HEADER_A_EXTENSION) */ /* source = a & RTP_HEADER_A_SOURCE */ /* payload_type = b & RTP_HEADER_B_PAYLOAD_TYPE */ /* marker = bool(b & RTP_HEADER_B_MARKER) */ }
NTP Timestamp
This is an NTP Timestamp as described in RFC 3450 Section 4. and RFC 1305. The timestamps used by iTunes and the device seems to come from a monotonic clock which starts at 0 when they just started/booted. This monotonic clock's origin of time is the unix epoch, which corresponds to 0x83aa7e80 seconds in NTP time.
/* sizeof(NtpTime) == 8 */ struct NtpTime { /* Seconds since 1900-01-01 00:00:00 (TODO: Timezone?) */ uint32_t integer; /* Fraction of second (0..2^32) */ uint32_t fraction; }
RTP Timestamp
This is a 32 bit network order value increasing by 1 for each frame of data transmitted, which means it increases by FRAMES_PER_PACKET for every RTP packet sent.
TimingPacket
/* sizeof(TimingPacket) == 32 */ struct TimingPacket { RtpHeader header; uint32_t zero_padding; NtpTime reference_time; NtpTime received_time; NtpTime send_time; }
SyncPacket
/* sizeof(SyncPacket) == 20 */ struct SyncPacket { RtpHeader header; RtpTimestamp now_minus_latency; NtpTime time_last_sync; RtpTimestamp now; }
ResendPacket
/* sizeof(RtpResendPacket) == 8 */ struct RtpResendHeader { RtpHeader header; uint16_t missed_seqnum; uint16_t count; }
Constants
Name | Value | Description |
---|---|---|
FRAMES_PER_PACKET | 352 | Audio frames per packet |
SHORTS_PER_PACKET | 2 * FRAMES_PER_PACKET | Shorts per packet |
TIMESTAMPS_PER_SECOND | 44100 | Timestamps per second |
TIMESYNC_INTERVAL | 44100 | Once per second |
TIME_PER_PACKET | FRAMES_PER_PACKET / 44100 | Milliseconds |
PACKET_BACKLOG | 1000 | Packet resend buffer size |
RTSP
Common request headers
Client-Instance | 64 random bytes in hex. Must be unique per
connection.
|
CSeq | Request sequence number. Can either be counted
locally or response sequence number can be
increased by one.
|
RTP-Info | rtptime={RTP timestamp} |
Session | Server session ID (after SETUP) |
User-Agent | iTunes/{Version} (Windows; N;)
(e.g. Version=``iTunes/7.6.2 (Windows; N;)``)
(for a mac, this looks like User-Agent: iTunes/9.2.1
(Macintosh; Intel Mac OS X 10.5.8) AppleWebKit/533.17.8)
|
Request URI
Unless specified otherwise, rtsp://{Local IP address}/{Client session ID} must be used as the request URI. The client session ID is a random number between 0 and 2^32 generated once per connection.
Note that the Local IP address cannot be a Link Local address (i.e. it cannot begin with 169.254) - it must be the primary IP address of the Airport, which is the first address record listed in the Airport's RAOP service announcement.
ANNOUNCE
Headers | Content-Type: application/sdp
|
Body | v=0\r\n
o=iTunes {Client session ID} O IN IP4 {Local IP address}\r\n
s=iTunes\r\n
c=IN IP4 {Server IP address}\r\n
t=0 0\r\n
m=audio 0 RTP/AVP 96\r\n
a=rtpmap:96 AppleLossless\r\n
a=fmtp:96 {Frames per packet} 0 16 40 10 14 2 255 0 0 44100\r\n
a=rsaaeskey:{AES key in base64 w/o padding}\r\n
a=aesiv:{AES IV in base64 w/o padding}\r\n
\r\n
|
FLUSH
Headers | RTP-Info: seq={Last RTP seqnum};rtptime={Last RTP time} |
OPTIONS
URI | * |
Headers | Apple-Challenge: {16 random bytes in base64 w/o padding} |
RECORD
Headers | Range: ntp=0-
RTP-Info: seq={Note 1};rtptime={Note 2}
|
Note 1: Initial value for the RTP Sequence Number, random 16 bit value
Note 2: Initial value for the RTP Timestamps, random 32 bit value
SET_PARAMETER
Setting volume
Headers | Content-Type: text/parameters |
Body | volume: %f |
Volume is either -144.0 (muted) or (-30.0)..(0.0).
Set progress
Headers | Content-Type: text/parameters |
Body | progress: %f/%f/%f |
Values are RTP timestamp as unsigned integers (TODO).
Set DAAP metadata
Headers | Content-Type: application/x-dmap-tagged
|
Body | DAAP metadata |
SETUP
Headers | Transport: RTP/AVP/UDP;unicast;interleaved=0-1;mode=record;control_port={Control port};timing_port={Timing port} |
Get server_port, control_port and timing_port from Transport response header. Get Session response header and use it as server session ID. The Audio-Jack-Status header is part of this response too.
TEARDOWN
Nothing special.
Rogue Amoeba extensions
X_RA_SET_ALBUM_ART
Use this only if server wants PList metadata. Use the SET_PARAMETER method if DAAP metadata is requested.
Headers | Content-Type: {Image content type}
|
Body | Image data |
X_RA_SET_PLIST_METADATA
Headers | Content-Type: application/xml
|
Body | Metadata in PList format |
Authentication
AirTunes 2 uses the HTTP Digest authentication method as described in RFC2617.
Detect speaker type
If Audio-Jack-Status is in response:
speaker_type() { if ("disconnected" in Audio-Jack-Status) { return unplugged; } else if ("connected" in Audio-Jack-Status) { if ("digital" in Audio-Jack-Status) { return digital; } return analog; } return unknown; }
Detect metadata and audio latency
If Apple-Response, Server or Audio-Latency in response:
if (Apple-Response in response) { lowercase_password = False; audio_format = EncryptedALAC; wants_album_art = False; wants_metadata = False; wants_progress = False; has_bad_latency_header = False; } if (Server in response) { lowercase_password = True; has_bad_latency_header = True; if (not Apple-Response in response) { audio_format = UnencryptedALAC; wants_album_art = DAAP; wants_metadata = DAAP; wants_progress = True; } } if (Audio-Latency in response) { if (not has_bad_latency_header) { audio_latency = Audio-Latency; } else { if (Audio-Latency == 322 or Audio-Latency == 15049) { audio_latency = 11025; } /* Why always 11025? */ audio_latency = 11025; } }
Timing
The server will send Timing request UDP packets to the timing port. The sender will answer to this Timing request with a Timing response UDP packet sent to the server timing port.
Replying to timing packet
on_timing_packet(TimingPacket req) { assert req.header.payload_type == PAYLOAD_TIMING_REQUEST; TimingPacket res; res.header = req.header; res.header.payload_type = PAYLOAD_TIMING_RESPONSE; /* these 3 times are NTP times (ie 64 bit values) */ res.reference_time = req.send_time; res.received_time = time_now(); res.send_time = time_now(); /* TODO: is req.send_time the time on the server? the (virtual) NTP time * of the audio packet that is being played by the server? Is one of the * other timestamp the time on the sender, and the other one, some kind of * "common time" to be used by the server and the sender? */ send(res); }
Sync
Sync packets are sent once per second or when adding a speaker. They are sent to the device control port as UDP packets. The timestamp argument corresponds to the RTP timestamp of the next audio packet that will be sent. The latency argument is gathered from the Audio-Latency RTSP header. First is set on the first packet and after a FLUSH.
Sending sync packet
send_sync(uint32_t timestamp, uint32_t latency, bool first) { SyncPacket packet; packet.header.payload_type = PAYLOAD_SYNC; packet.header.marker = True; packet.header.seqnum = 7; /* Why fixed? */ if (first) { packet.header.extension = True; } packet.now_minus_latency = timestamp - latency; packet.now = timestamp; packet.time_last_sync = time_of_last_sync_packet; }
Audio
Audio packet
Header:
/* The first 4 bytes are an RtpHeader */ { 0x80, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, {A}, {B}, {C}, {D} }
{A}, {B}, {C}, and {D} are four random bytes that are generated per-session.
Audio codec
Codec | Apple Lossless (ALAC) |
Sample size | 16 Bit |
Channels | 2 |
Sample rate | 44100 |
Packetizing audio
- Collect FRAMES_PER_PACKET frames from input data (each frame is 2 bytes)
- Encode input frames using ALAC codec
- Encode packet data
- Raw L16
- Convert raw input data to big endian (it's an array of uint16)
- Copy audio header and converted audio data into one buffer
- Set 2nd byte of buffer to 0xa
- Unencrypted ALAC
- Copy audio header to buffer
- Append ALAC encoded audio data to buffer
- Encrypted ALAC
- Encrypt ALAC encoded audio data (only complete 16 byte blocks, the rest stays unencrypted)
- Copy audio header to buffer
- Append encrypted audio data to buffer
- Raw L16
Metadata
DAAP metadata
Content-type | application/x-dmap-tagged |
Item name field | dmap.itemname |
Artist field | daap.songartist |
Album field | daap.songalbum |
PList metadata
Content-type | application/xml |
Title field | title |
Artist field | artist |
Album field | album |
Zeroconf TXT record
Field | Description |
---|---|
txtvers | TXT record version (always 1) |
pw | true if password required, false otherwise |
sr | Audio sample rate |
ss | Audio bit rate |
ch | Number of audio channels |
tp | Protocol (UDP [TODO: or TCP?]) |
Rogue Amoeba extensions
Field | Description |
---|---|
rast | afs if Airfoil speaker |
ramach | {Platform name}.{OS major version} |
raver | Library version |
raAudioFormats | ALAC or L16 |