Sound Control Protocol for ew D1

SSC Developer‘s guide for evolution wireless D1 | 23/56
General SSC Address Schema
Example:
TX: { "osc": { "state": {"baseaddr":[{ "out1": {"xlr2": null}}] }}
RX: { "osc": { "state": {"baseaddr":[{ "out1": {"xlr2": null}}] }}
TX: { "gain": -10 }
RX: { "gain": -10 }
The SSC Client may query the server for the support of this feature by invoking /osc/feature/base-
addr.
5.1.12 SSC timed method execution - /osc/timetag
When this method is called as part of an SSC Message, all the SSC Method Calls contained in the
same Message are to be executed by the SSC Server at a time determined by the timetag parameter.
Compare section 4.3.5.
TX: { "osc": { "ping": null, "timetag": 3.0 }}
... 3 seconds pass ..
RX: { "osc": { "ping": null }}
5.1.13 SSC Method time stamps - /osc/timestamp
This method may be called as part of an SSC Message to estimate the communication delay and
clock offset between SSC Client and server. Like in NTP or PTP, four timestamps are used, forming
an array. The SSC Client sends the method call and provides the array containing the first, client-side
timestamp. The SSC Server will add two server-side timestamps in the SSC Method Reply, and finally
the client can insert the fourth timestamp upon reception of the Reply Message.
The four timestamps are:
• sending time of the Message from the SSC Client as value of the client /device/time
• reception time at the SSC Server as value of the server /device/time
• sending time of the Reply at the SSC Server, value of server /device/time
• reception time of the Reply at the client, value of client /device/time
Example:
TX: { "osc": { "ping": null, "timestamp": [ 396711511.044569 ] }}
RX: { "osc": { "ping": null,
"timestamp": [ 396711511.044569, 396711500.05,
396711500.08, 396711511.644569 ] }}
Support for timestamps is optional. If the SSC Server doesn’t implement it, it shall omit the time-
stamp completely from the Reply Message.
5.1.14 SSC Method Authorisation - /osc/tan
In some applications (like conference systems), remote configurability of SSC devices might pose a
security risk, because some attacker with access to the LAN might remotely gain access to sensitive
audio streams by reconfiguring devices.
Transaction Authorisation Numbers (TANs) are a simple but efficient means to control configuration
access without relying on complex cryptographic protocols, which might be too complex for environ-
ments like media control systems.
A list of TAN numbers is distributed between the SSC devices in a system. The SSC Client must pro-
vide a valid TAN with each SSC Method Call. The SSC Server refuses to execute the method if it finds
the TAN to be invalid. Each TAN may only be used once.
How the TAN list is distributed between the SSC devices in a system is out of the scope of this spec-
ification.
TX: { "osc": { "ping": null, "tan": "1124frvso!" }}
RX: { "osc": { "ping": null }}
TX: { "osc": { "ping": null, "tan": "1124frvso!" }}
RX: { "osc": { "error": [{
"osc": { "tan": [{"code": 403, "desc": "TAN invalid"}],
"ping": [{"code": 403, "desc": "forbidden"}] }}] }}