NMOS is a family of free, open, vendor neutral APIs, intended as a means of encouraging interoperability between networked media applications developed by AMWA. One philosophy within the NMOS architecture is to incorporate existing standards and conventions where possible, rather than to define a new set of specifications – a perfectly sensible approach, given the mass of interconnecting and often incompatible legacy standards already in existence. Use of DNS-SD for example to advertise APIs, allows in principle a zero-config deployment of NMOS enabled devices into a production environment.
As a set of specifications intended to encourage interoperability, it therefore stands out that one inclusion within the NMOS architecture is a rather inconvenient standard by which the most crucial information (i.e the actual properties of the audio and video that are ultimately being managed) is exchanged.
Session Description Protocol is a somewhat loosely structured format, typically used to advertise the connection and format details of a VoIP or video conferencing session. The <key>=<value> syntax can be pieced together by exploring a number of revisions and amendments across various RFC documents, but the restriction of having a single character before the “=” on each line, combined with several parameters being stitched into a space separated string, results in the protocol being neither machine friendly, nor human readable.
Furthermore, the typical properties that any media application is likely to be “most interested in” – e.g. frame rate, resolution – are lumped together in one such single line (although in this case separate by semicolons rather than spaces), where even the key/value syntax is sporadically eschewed. Below is a typical SDP manifest from a ST-2110-20 uncompressed video sender, with some “quirks” highlighted (Note: blank lines included for clarity are NOT valid in SDP).
- Don’t forget the hyphen if not providing a “username” for the origin (o=)
- In the connection information (c=), the integer following the IP address and slash is in fact the TTL as opposed to the typical <IP>/<netmask> notation
- Video parameters in the “fmtp” attribute (a=) line are all in the key=value format, except for “interlace;”
- Due to phrasing and diagrams in SMPTE RP 2110-23:2019, Section 5.3, some NMOS vendor implementations have a requirement for the “mid” attribute to be at the end of each media stanza.
Also of note:
- Various occurrences of “IN” are short for IN-ternet
- The SDP file must end with a new line.
- “exactframerate”, when expressed as a fraction should not produce values such as “25000/1001”
And many more we have missed…
The SDP validator SDPoker is recommended for verification of SDP files, though this is not a guarantee that files will be compatible between vendor products.
The use of a simple text based format from the 1990s feels rather at odds with the otherwise almost entirely JSON based RESTful API structure. Moreover, the majority* of the content of the SDP is in fact already present within the IS-04 API schema – albeit distributed across a few URLs – meaning it should be possible to convey/retrieve all of the necessary information as part of the exchange of the JSON formatted API calls.
* ST 2110-30 audio packet interval is only available within the SDP
Instead, the IS-04 specification mandates that the URL for the SDP manifest be advertised by NMOS senders in both registered operation and peer-to-peer mode, in order for controllers and receivers to identify exactly what is contained within the flow.
In summary: An exchange of JSON content is required, just to establish the location of the important information that is stored in a less computer-friendly format…
As a result, it has become a major pain point for a number of early NMOS adopters having to test and report SDP incompatibilities between products, whilst manually fixing, or even in-house development to parse and transform SDP from various devices in order to integrate with the NMOS registry and controllers.
