Control and MIDI Data Ports

A participant creates two UDP ports, using an arbitrary pair of consecutive port numbers. The Apple driver attempts to reuse ports from the last time it ran; otherwise, it finds and uses a pair of unused ports.

• Port N is the control port.

• Port N+1 is the MIDI communication port.

The Apple driver advertises the control port via Bonjour using the service name "_apple-midi._udp".

Session Initiation and Termination

To set up a session, the participants exchange several types of command packets. Exchange packet formats shows the common structure of these packets. Each row in this figure (and other figures in this document) describes a 32-bit value stored in the packet. All numbers are stored in network byte order unless otherwise stated.

The full sequence of packets sent to establish a session is:

1. Initiator sends an Invitation ('IN') packet on control port

   This is a request to create a connection. The sender is the "initiator"; the receiver is the "responder." The name field should be included. Invitation requests are resent every second, up to 12 times, until an Invitation Accepted or Invitation Rejected response is received.

2. Responder sends an Invitation Accepted ('OK') or Invitation Rejected ('NO') packet on control port

   A participant has received an invitation and is responding to it. In its response, the responder should copy the initiator token from the received invitation, but use its own SSRC identifier. The name field should be included in an Invitation Accepted packet and excluded from an Invitation Rejected packet. If the invitation was rejected, no further packets are exchanged.

3. Initiator sends an Invitation ('IN') packet on MIDI port

4. Responder sends an Invitation Accepted ('OK') or Invitation Rejected ('NO') packet on MIDI port

   A participant has received an invitation and is responding to it. In its response, the responder should copy the initiator token from the received invitation, but send its own SSRC identifier. The name field should be included in an Invitation Accepted packet and excluded from an Invitation Rejected packet. If the invitation was rejected, no further packets are exchanged.

5. Initiator initiates clock synchronization (see Timestamp Synchronization)

Timestamp Synchronization

This feature of the protocol provides a common basis for the timestamps in the MIDI RTP payload data packets. The degree of accuracy possible with this method varies with network conditions, but on a local network, it is possible for a receiver to know when a MIDI event occurred (or is scheduled to occur) with a high degree of accuracy, within 1-2 ms.

The thread servicing a participant's control port may run at a relatively normal priority, whereas the thread servicing a participant’s MIDI port should run at a high priority in order to process incoming MIDI responsively.

Synchronization packets are exchanged between the participants' MIDI ports. The packet format is shown in Timestamp packet structure.

The original initiator initiates clock synchronization after the end of the initial invitation handshake packets. A full clock synchronization exchange is as follows:

1. Initiator sends sync packet with count = 0, current time in timestamp 1

2. Responder sends sync packet with count = 1, current time in timestamp 2, timestamp 1 copied from received packet

3. Initiator sends sync packet with count = 2, current time in timestamp 3, timestamps 1 and 2 copied from received packet

At the end of this exchange, each party can estimate the offset between the two clocks using the following formula:

offset_estimate = ((timestamp3 + timestamp1) / 2) - timestamp2

Furthermore, by maintaining a history of synchronization exchanges, each party can calculate a rate at which the clock offset is changing.

The initiator must initiate a new sync exchange at least once every 60 seconds; otherwise the responder may assume that the initiator has died and terminate the session.

Exchanging MIDI Packets

The participants in a session exchange MIDI packets between the participants' MIDI data ports. A MIDI packet consists of a header, a MIDI command section and a journal session. The format of the packet header is shown in MIDI packet header format, with a few limitations and assumptions made.

The timestamp is in the same units as described in Timestamp Synchronization (units of 100 microseconds since an arbitrary time in the past). The lower 32 bits of this value is encoded in the packet. The Apple driver may transmit packets with timestamps in the future. Such messages should not be played until the scheduled time. (A future version of the driver may have an option to not transmit messages with future timestamps, to accommodate hardware not prepared to defer rendering the messages until the proper time.)

The MIDI command section is shown in MIDI command section format and matches the format defined in RFC 6295.

Here are some specific details about how Apple’s driver uses MIDI packets:

• The Apple driver always transmits a recovery journal (J=1) but does not require one in received packets.

• The Apple driver codes all MIDI 1.0 messages as specified by the RTP protocol. The behavior of the undefined MIDI messages (0xF4, 0xF5, 0xF9 and 0xFD) is undefined.

• The Apple driver transmits guard packets. These are packets containing no new MIDI information, only recovery journals.

Receiver Feedback Transmitted to the Sender

The recovery journal mechanism requires that the receiver periodically inform the sender of the sequence number of the most recently received packet. This allows the sender to reduce the size of the recovery journal, to encapsulate only those changes to the MIDI stream state occurring after the specified packet number.

This message is sent on the control port. Its format is described in Journal feedback packet format.