Sound Control Protocol for ew D1

SSC Developer‘s guide for evolution wireless D1 | 27/56
SSC Transport Layer Adaptations
6. SSC Transport Layer Adaptations
The SSC data format as defined in the previous sections can be transported by different transport
protocols, or stored in persistent files. This section specifies what transports are supported, and how
the specific features of transport layers shall be applied to transporting SSC Messages.
6.1 UDP/IP
UDP/IP is the standard transport for all devices with an Ethernet interface or another interface typi-
cally used for internet connectivity. All those device MUST implement the UDP/IP transport for SSC.
All devices SHALL implement UDP over IPv6. Support for UDP over IPv4 is OPTIONAL.
One UDP datagram is used to transport one SSC Message. If the SSC Message is really large (e.g., a
complete device configuration), IP fragmentation might fail, if a restricted device does not implement
IP re-assembly properly. In that case, the SSC Server should break up the message into multiple SSC
Method Calls instead. If atomic execution is relevant, SSC time tags may be used.
The UDP port number to used by the SSC Server should normally be discovered by the SSC Client by
means of the server discovery protocol. The default port number is 45.
Rationale: No other standard UDP service is expected to use 45. The IANA reservation for a "Message
Passing Service" is historic, and SSC is actually passing messages itself. Sennheiser was founded in
1945.
6.2 TCP/IP
Support for transporting SSC Messages over TCP/IP is OPTIONAL. An SSC device choosing to sup-
port TCP/IP SHOULD support the same set of IP versions for TCP as well as for UDP.
One important application for TCP/IP is to integrate SSC devices into media control systems. In these
systems ease of use of the protocol is of special relevance.
TCP/IP is a byte-stream based transport. Therefore it is necessary to define a way of fragmenting the
stream into SSC Messages.
The following two-character sequences are recognised as an SSC Message separator:
• ASCII carriage return (13) – newline (10)
• ASCII newline (10) – newline (10)
Rationale: An unescaped newline cannot appear in the data of a legal SSC Message. The newline
character supports interactive use of SSC. Newline alone as single separator character would pre-
vent formatting a large SSC Message over multiple lines (important to store SSC Messages in read-
able or editable text files).
To support interactive use, SSC Servers providing TCP transport MAY implement the SSC base ad-
dress feature. They MAY also support the relaxed SSC parser as specified in the appendix.
SSC Messages containing time-critical commands should be pushed (TCP flag PSH) through the TCP
stack for minimum latency, after writing the Message separator sequence.
The TCP port number to be used by the SSC Server is expected to be discovered by the client by
means of the server discovery protocol. The default port number is 45.
Rationale: Same as UDP.
6.3 HTTP(S)/TCP/IP
Support for transporting SSC Messages over HTTP over TCP is OPTIONAL. If an SSC Server provides
the HTTP transport, it MUST also provide TCP transport. Consequentially, HTTP MUST be provided
over the same set of IP versions as UDP. An SSC Server supporting HTTP SHOULD support HTTP
version 1.1.
HTTP should be provided by those SSC Server devices that should be easily accessible for control
apps based on smart phone, tablets, or web-apps (might be served by the device itself).
SSC Messages are transported as HTTP request or reply contents. The MIME-Type of the contents
MUST be specified as "application/json" in the HTTP header field "Content-Type". Using this MIME-