Standards: Part 12 - ST2110 Part 10 - System Level Timing & Control
![](/cache/uploads/content_images/Standards_Part_12_789_500_70_s.jpg)
How ST 2110 Part 10 describes transport, timing, error-protection and service descriptions relating to the individual essence streams delivered over the IP network using SDP, RTP, FEC & PTP.
This article is part of our growing series on Standards.
There is an overview of all 26 articles in Part 1 - An Introduction To Standards.
ST 2110 is built on a foundation provided by the systems layer described in Part 10. That describes how streams are announced and discovered by receivers and how they are synchronized precisely when each essence stream is delivered separately. Latency is reduced by pre-empting packet losses with redundant error correcting information in the transport streams instead of using the slower TCP transport.
Part 10 describes these core parts of the system architecture:
- Session Description Protocol (SDP).
- Real Time transport Protocol (RTP) streams.
- Forward Error Correction (FEC) techniques.
- Precision Time Protocol (PTP).
The AMWA NMOS specifications augment ST 2110 with application level protocols and metadata which are integral to deploying your ST 2110 installation. They are all relevant and freely available to download. NMOS and other useful standards are described in the appendices.
Session Description Protocol (SDP)
The Session Description Protocol (SDP) announces streams and services that are vended by server-nodes in your network. A client-node discovers these and can access them as a live-feed source using the details contained in the SDP message.
Refer to Section 8 and Annex B of the ST 2110-10 standard for details of how SDP is used in the ST 2110 environment. This is based on RFC documents published by the IETF. Those documents have been revised several times and the most recent version replaces all of the earlier revisions even if ST 2110 does not track the changes:
Document | Version | Description |
---|---|---|
RFC 2327 | 1998 | Original Session Description Protocol description. Obsoleted by RFC 4566. |
RFC 3266 | 2002 | Support for IPv6 added to SDP. Obsoleted by RFC 4566. |
RFC 4566 | 2006 | Revised SDP specification which replaces RFC 2327. Obsoleted by RFC 8866. |
RFC 8866 | 2021 | The most recent draft specification of the Session Description Protocol (SDP). This describes multimedia communication sessions for announcement and invitation to access streaming services. This is a proposed improved version that obsoletes all prior specifications. |
The Session Description Protocol (SDP) announces available streams as they are deployed using a well-known multicast IP address which is reserved for that purpose. All nodes on the sub-net will see those announcements and can act on them to acquire the details of the remote stream if they qualify for the invitation.
The SDP message is carried as a payload in a Session Announcement Protocol (SAP) packet. These are retransmitted periodically so that latecomers can also receive them. Here is an example SDP payload taken from Annex B of the ST 2110-10 standard:
Despite it appearing complex, this is a simple format to construct. Some of the data items will already have been defined as configuration settings and will be the same for all sessions. Others are unique to this announcement.
Real Time Transport Protocol (RTP) Streams
ST-2110 is built on Real Time transport Protocol (RTP) streams. These were originally described in RFC documents and have been revised and extended many times since they were first introduced. RTP is extensible. Alter the behavior to suit your needs. The streams are all locked to a common timing reference defined by the Precision Time Protocol (PTP) and time-stamped with markers at the beginning of each video frame.
ST 2110 is based on the RTP protocol as originally defined by the IETF in RFC 3550 with the further caveat that it should conform to the profile defined in RFC 3551. These RFC documents are easy to find and download to read and understand the fine detail.
These RFCs have been continually revised and updated but ST 2110-41 mandates that ST 2110 shall continue to be based on the RFC 3550 definition of RTP. Future revisions to ST 2110 might take later enhancements to RTP into account but there is no indication of that happening yet:
Document | Version | Description |
---|---|---|
RFC 3550 | 2003 | RTP: A Transport Protocol for Real-Time Applications. The base specification used by ST 2110. |
RFC 3551 | 2003 | An RTP Profile for Audio and Video Conferences with Minimal Control. Also mandated by ST 2110. |
RFC 5506 | 2009 | Support for Reduced-Size Real-Time Transport Control Protocol (RTCP). |
RFC 5761 | 2010 | Multiplexing RTP Data and Control Packets on a Single Port. |
RFC 6051 | 2010 | Rapid Synchronization of RTP Flows. |
RFC 6184 | 2011 | RTP Payload Format for H.264 (AVC) Video. |
RFC 6190 | 2011 | RTP Payload Format for Scalable Video Coding (SVC). |
RFC 7007 | 2013 | Update to Remove DVI4 from the Recommended Codecs listed in RFC 3551. |
RFC 7022 | 2013 | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs). |
RFC 7160 | 2014 | Support for Multiple Clock Rates in an RTP Session. |
RFC 7164 | 2014 | RTP and Leap Seconds. |
RFC 7656 | 2015 | A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources. |
RFC 7798 | 2016 | RTP Payload Format for High Efficiency Video Coding (HEVC). |
RFC 8035 | 2016 | Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing. |
RFC 8083 | 2017 | Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions. |
RFC 8108 | 2017 | Sending Multiple RTP Streams in a Single RTP Session. |
RFC 8858 | 2021 | Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP). |
RFC 8860 | 2021 | Sending Multiple Types of Media in a Single RTP Session. |
Forward Error Correction (FEC)
The RTP streams are delivered using UDP transports. These have low latency but can suffer from packet loss and sequence order scrambling. Buffering and retransmission solves that when you use TCP transports, but that introduces significant latency.
ST 2110 anticipates the potential packet loss by adding redundant data to facilitate the reconstruction of missing packets. This technique is called Forward Error Correction (FEC). It does add a small latency overhead because the entire FEC stream needs to be received and processed to potentially recover lost media packets.
There are two different levels of protection offered by FEC based on a row and column arrangement that organizes the packets into a two-dimensional grid:
- Level A - Column only protection.
- Level B - Column and row protection.
The following standards are relevant to understanding FEC and how it fits into the RTP context:
Document | Org | Version | Description |
---|---|---|---|
ST 2022-5 | SMPTE | 2013 | Forward Error Correction for Transport of High Bit Rate Media Signals over IP Networks. |
ST 2022-6 | SMPTE | 2012 | Transport of High Bit Rate Media Signals over IP Networks. |
ST 2022-7 | SMPTE | 2019 | Seamless Protection Switching of RTP Datagrams briefly mentions FEC. |
Sometimes the word 'Datagram' is used. In the context of ST 2110 and IP, this is interchangeable with the term 'Packet'.
Read ST 2022 Part 5 for a detailed explanation of how FEC works.
FEC Protection - Level A
Level A protection is a one-dimensional arrangement with a sequence of media packets aggregated to create a single FEC packet. The length of this sequence is defined by your configuration settings. The media packets are transmitted to a designated IP port at the client node. The FEC data is transmitted separately to a separate but nearby port. This technique is resilient to the loss of a single packet.
FEC Protection - Level B
Level B protection works on a two-dimensional grid of media packets with a FEC packet separately created for each column and row. The FEC is calculated for a column in the same way as Level A. The columns are stacked in rows based on the configured column length. If the column length is set to 100 packets then every 100th packet will start a new column.
There are a variety of different ways to arrange these columns. ST 2022 Part 5 discusses the advantages of offsetting the columns.
FEC Stream Arrangement
The FEC packets are transmitted separately to the media in their own RTP stream. This allows them to use an RFC 3550 compliant packet header without alterations to add FEC protection. The column and row FEC streams are transmitted separately so that they can have their own sequence numbers.
RFC 3550 mandates that a media stream is delivered to an evenly numbered port (N) at the destination IP address. The supporting column based FEC packets for a Level A connection will be sent to port number N+2 at the same address. For a level B connection, the column packets will be sent to the same relative port (N+2) and the row FEC packets will be sent to port number N+4. Therefore, each incoming stream can potentially require 3 evenly numbered IP ports to be allocated at the receiving client.
The receiver processes the media stream to check the packet sequence numbers and reconstruct any missing packets by combining the incoming media and FEC packets on the associated streams.
There is more information on FEC in these appendices:
Standards: Appendix R - The XOR Process Used In FEC Calculations
Standards: Appendix S - Forward Error Correction Ranges & Limits
Precision Time Protocol (PTP)
ST 2110 relies on the IEEE Precision Time Protocol (PTP) to synchronize timing and control signals. Part 10 describes the interaction between RTP streaming and PTP timing synchronization.
Clients synchronize to a reference clock by exchanging messages and measuring the propagation time for the round trip. The observed journey duration indicates an offset from the reference time. The local clock is adjusted to take that transmission latency into account. These assumptions determine the reliability of the local clock:
- The transmission time is constant over any period of time.
- The transmission time is the same in both directions.
- Both endpoints can accurately determine the message departure and arrival times.
These standards are relevant to PTP in the context of an ST 2110 system:
Document | Org | Version | Description |
---|---|---|---|
IEEE 1588 | IEEE | 2002 | PTP version 1 using IPv4 transports. |
IEEE 1588 | IEEE | 2008 | PTP version 2, which is not backwards compatible with version 1. This version introduces profile support and includes IPv6 transport as well. |
IEEE 1588 | IEEE | 2018 | Sometimes informally described as PTP version 2.1, this improves the 2008 version to provide backwards compatibility. |
IEEE 802.1AS | IEEE | 2020 | Adapted from PTP for Audio Bridging applications in local area networks. This includes Wi-Fi and Bluetooth applications. |
TR-1001 | JT-NM | 2020 v1.1 | System Environment and Device Behaviors For SMPTE ST 2110 Media Nodes in Engineered Networks. This specification enables simplified network configuration, registration and connection management for media nodes. It illustrates how the Precision Time Protocol is used in an ST 2110 installation. |
Conclusion
It is important to read ST 2110 Part 10 before the rest of the standard. The background information in the supporting documents from other sources will also help you understand how the systems layer works.
Beware that ST 2110 sometimes mandates earlier versions of external standards. Nevertheless, it is still important to be conversant with the latest versions in case ST 2110 is revised to accommodate them.
There is more information on standards relating to discovery and control within ST 2110 in these two appendices:
Standards: Appendix P - Other Relevant Standards For Discovery & Control
These Appendix articles contain additional information you may find useful:
Part of a series supported by
You might also like...
Is AI “Just A Tool”?
People often say that AI is just a tool. But it’s not. That’s a fundamental mistake and likely to be wrong by several orders of magnitude.
Designing IP Broadcast Systems: Software Defined Networking
SDNs are relatively new to IT and are making great milestones into optimizing networks to improve their performance, especially for heavy hitting media flows.
KVM & Multiviewer Systems At IBC 2024
We take a look at what to expect in the world of KVM & Multiviewer systems at the 2024 IBC Show.
Standards: Part 16 - About MP3 Audio Coding & ID3 Metadata
The MP3 audio format has been around for thirty years and has been superseded by several other codecs – so here we discuss why it still has a very strong position in broadcast. We also discuss ID3 metadata tags which often a…
HDR Picture Fundamentals: Brightness
This article describes one of the fundamental principles of broadcast - how humans perceive light, how this relates to the technology we use to capture and display images, and how this relates to HDR & Wide Color Gamut