Sound Control Protocol for ew D1

Table Of Contents
SSC Developer‘s guide for evolution wireless D1 | 16/56
General SSC Address Schema
403 forbidden
404 address not found
406 not acceptable (e.g., wrong type for parameter)
408 request time out
409 conflict
410 gone
413 request too long
414 request too complex
422 unprocessable entity (error in a complex method parameter)
423 locked
424 failed dependency
450 answer too long
454 parameter address not found (e.g., address in a subscription request)
5xx – Server Error
500 internal server error
501 not implemented
503 service unavailable
5.1.3 SSC transaction ID - /osc/xid
When an SSC Clients calls the Method /osc/xid, the parameters supplied for the method will be
reflected back in the Method Reply of the SSC Server. This can be used by the client to keep track of
client-side per-server state.
TX: { "osc": { "xid": 1234567, "version": null }}
RX: { "osc": { "xid": 1234567, "version": "1.1" }}
See also section 5.1.9 for a special application of this Method to subscriptions.
5.1.4 SSC Ping - /osc/ping
When a client invokes the /osc/ping method the server will immediately respond with an /osc/ping
response with identical result as invoked.
With no parameters:
TX: { "osc": { "ping": null }}
RX: { "osc": { "ping": null }}
With some parameters:
TX: { "osc": { "ping": [ "abcdefghijklm", 3.14159 ] }}}
RX: { "osc": { "ping": [ "abcdefghijklm", 3.14159 ] }}}
5.1.5 SSC Schema reflection - /osc/schema
The /osc/schema method exists to allow clients to query servers about what address schemes are
available on a specific server.
For instance, in our standard example the following Method Call on the top level /out1 address
TX: { "osc": { "schema": [ { "out1": null } ] }}
would return the following SSC Reply Message which describes the addresses that are contained in
the /out1 address one level deep:
RX: { "osc": { "schema": [
{ "out1": { "xlr1": {}, "xlr2": {} }} ] }}