OSC (OpenSoundControl) is a simple format for packaging messages. It supports a variety of data types and also bundles of messages. In DoIP, OSC is a very suitable transport format. It is currently commonly implemented on top of UDP and TCP (both run on top of IP). The UDP implementation (OSC/UDP) is very simple, because it allows you to send a message to a device at any time. The TCP (OSC/TCP) implementation is a little more complex, because a device will have to maintain a connection to another device. Nevertheless, the TCP implementation is more reliable (it will resend packets if they are lost) and also supports replies from the device.

See the list of value types for more information on how HomeWeave values are transported over OSC and converted back and forth.

In the OSC over UDP implementation, UDP is used to send packets containing OSC messages or message bundles to devices. In the definition file, the type of the transport is 'udp', the format 'osc' and there is no framing set. If no address is specified, the client device simply uses the address of the advertising device. A device can specify another device's IP address (for instance, if that device does not support discovery or negotiation, but does support a certain set of OSC messages) or a multicast IP address. In each UDP packet, there should be a single OSC message or bundle.

When TCP is used, the type in the definition file is 'tcp', with format 'osc' and a framing type, which is required (usually, 'slip' is a good choice). A device connects to the address and port specified in the definition file; when no address is specified, it uses the address of the advertising device. Multicast addresses are not allowed here (TCP does not support multicast). The TCP connection is kept open by the receiving device, which listens for messages to come in. When SLIP framing is used, the messages are framed and the receiving device has to make sure that wrongly framed or incomplete messages are dropped while still processing the valid ones.

OSC over TCP also supports reply messages. If a device sends a reply for a specific message type, it has to send an (empty) reply for all supported messages. The reply consists of a single OSC message or bundle. The framing used on the reply channel is the same as used for receiving the messages. Replies should be sent in exactly the same order as the messages they reply to (this allows the sending device to link replies to sent messages).