Merge v1.1.x into v1.2-dev

APIs/schemas/activation-schema.json

@@ -1,6 +1,5 @@
 {
   "$schema": "http://json-schema.org/draft-04/schema#",
-  "type": "object",
   "title": "Activation resource",
   "description": "Parameters concerned with activation of the transport parameters",
   "type": "object",
@@ -23,7 +22,7 @@
       }]
     },
     "requested_time": {
-      "description": "String formatted TAI timestamp (<seconds>:<nanoseconds>) indicating time (absolute or relative) for activation. Should be null or not present if 'mode' is null.",
+      "description": "String formatted TAI timestamp (<seconds>:<nanoseconds>) indicating time (absolute or relative) for activation. Should be null or not present if 'mode' is null or activate_immediate.",
       "anyOf": [{
         "type": "string",
         "pattern": "^[0-9]+:[0-9]+$"

APIs/schemas/receiver_transport_params_mqtt.json

@@ -3,7 +3,6 @@
   "description": "Describes MQTT Receiver transport parameters. The constraints in this schema are minimum constraints, but may be further constrained at the constraints endpoint. MQTT Receivers must support all parameters in this schema.",
   "title": "MQTT Receiver Transport Parameters",
   "type": "object",
-  "title": "Receiver Input",
   "properties": {
     "source_host": {
       "type": [

APIs/schemas/receiver_transport_params_rtp.json

@@ -3,7 +3,6 @@
   "description": "Describes RTP Receiver transport parameters. The constraints in this schema are minimum constraints, but may be further constrained at the constraints endpoint. Receivers must support at least the `source_ip`, `interface_ip`, `rtp_enabled` and `destination_port` parameters, and must support the `multicast_ip` parameter if they are capable of multicast operation. Receivers supporting FEC and/or RTCP must support parameters prefixed with `fec` and `rtcp` respectively.",
   "title": "RTP Receiver Transport Parameters",
   "type": "object",
-  "title": "Receiver Input",
   "properties": {
     "source_ip": {
       "type": [

APIs/schemas/receiver_transport_params_websocket.json

@@ -3,7 +3,6 @@
   "description": "Describes WebSocket Receiver transport parameters. The constraints in this schema are minimum constraints, but may be further constrained at the constraints endpoint. WebSocket Receivers must support all parameters in this schema.",
   "title": "WebSocket Receiver Transport Parameters",
   "type": "object",
-  "title": "Receiver Input",
   "properties": {
     "connection_uri": {
       "type": [

APIs/schemas/sender_transport_params_mqtt.json

@@ -3,7 +3,6 @@
   "description": "Describes MQTT Sender transport parameters. The constraints in this schema are minimum constraints, but may be further constrained at the constraints endpoint. MQTT Senders must support all properties in this schema.",
   "title": "MQTT Sender Transport Parameters",
   "type": "object",
-  "title": "Sender Output",
   "properties": {
     "destination_host": {
       "type": [

APIs/schemas/sender_transport_params_rtp.json

@@ -3,7 +3,6 @@
   "description": "Describes RTP Sender transport parameters. The constraints in this schema are minimum constraints, but may be further constrained at the constraints endpoint. As a minimum all senders must support `source_ip`, `destination_ip`, `source_port`, `rtp_enabled` and `destination_port`. Senders supporting FEC and/or RTCP must support parameters prefixed with `fec` and `rtcp` respectively.",
   "title": "RTP Sender Transport Parameters",
     "type": "object",
-  "title": "Sender Output",
   "properties": {
     "source_ip": {
       "type": "string",

APIs/schemas/sender_transport_params_websocket.json

@@ -3,7 +3,6 @@
   "description": "Describes WebSocket Sender transport parameters. The constraints in this schema are minimum constraints, but may be further constrained at the constraints endpoint. WebSocket Senders must support all parameters in this schema.",
   "title": "WebSocket Sender Transport Parameters",
   "type": "object",
-  "title": "Sender Output",
   "properties": {
     "connection_uri": {
       "type": [

docs/Behaviour - RTP Transport Type.md

@@ -338,7 +338,7 @@ a=mid:Ch1
 
 ## Operation with RTCP
 
-RTCP provides various functions to support the operation of RTP, principally QoS reporting. RTCP is defined in Section 6 of RFC 3550, which suggests that the next highest odd port after the RTP port is used for its transmission. Where RTCP and forward error correction are both in use the RTP port SHOULD be chosen to be even, to satisfy the recommendations of both RFC 3550 and SMPTE 2022-5 without resulting in port collisions.
+RTCP provides various functions to support the operation of RTP, principally QoS reporting. RTCP is defined in Section 6 of RFC 3550, and Section 11 of RFC 3550 suggests that RTP use an even destination port number and the corresponding RTCP stream use the next higher (odd) destination port number. (Note: this convention will also satisfy the recommendations of ST 2022-5 for cases where forward error correction is used.)
 
 Senders and Receivers supporting RTCP SHOULD comply with RFC 3605 when creating and receiving SDP files. An RFC 3605 compliant SDP file is shown below, along with the transport parameters that would be presented on the `/staged` endpoint by a Receiver that has parsed the file.
 

examples/sender-stage-absolute-success.json

@@ -2,7 +2,7 @@
   "master_enable": true,
   "receiver_id": null,
   "activation": {
-    "mode": "activate_scheduled_relative",
+    "mode": "activate_scheduled_absolute",
     "requested_time": "1496759200:0",
     "activation_time": "1496759200:5000"
   },