Networked Media Open Specifications

Behaviour: RTP Transport Type

←Behaviour · Index↑ · Upgrade Path→

Transport File Resource

The Sender /transportfile resource should use the following HTTP header when returning the transport file:

Content-Type: application/sdp

Parameter Sets

Senders and Receiver Connection Management endpoints must support a core parameter set. In addition they may support multicast, FEC and/or RTCP parameter sets. Endpoints must support all parameters in a parameter set, or none at all.

Receiver Parameter Sets

Core Parameters

Multicast Parameters

FEC Parameters

RTCP Parameters

Sender Parameter Sets

Core Parameters

FEC Parameters

RTCP Parameters

Use of auto

Parameters which support use of auto are identified in the schemas. Where it is unclear how auto should be interpreted this is noted below.

Sender source_ip and Receiver interface_ip

These parameters specify the interface binding to use for sending or receiving traffic. Use of auto here implies the Device should determine for itself which of its interfaces is the most appropriate to use. In Devices where only one interface is available for media traffic this is trivial. In Devices with multiple media network interfaces Devices may use mechanisms such as routing tables, out-of-band controls or evaluation of loading on the interfaces.

Sender destination_ip

If this parameter is set to auto the Sender is expected to automatically select an address to send on. This may be determined by an external network control system, or through technologies such as MADCAP (RFC 2730) or ZMAAP.

Behaviour of SDP Media Information

SDP files contain both connection information and media information. When a parameter set is activated with an SDP file present in data the Receiver should use the media information in the SDP file.

Interpretation of SDP Files

All Senders and Receivers should comply with RFC 4566 (Session Description Protocol) when creating and parsing SDP files. Multicast Senders and Receivers should additionally comply with RFC 4570 (SDP Source Filters). Three examples are given below, showing an SDP file and the transport parameters that would be presented at the /staged endpoint by a single-legged Receiver that has parsed the file.

A Receiver sets the rtp_enabled parameter to true for each leg it has configured from the SDP file, unless overridden by the requested transport_params as noted below.

In the event that a Receiver is presented with an SDP file and a set of transport parameters that contradict each other in the same PATCH request, the transport parameters take priority over the SDP file and must be the parameters used for activation. This only applies in the case where there is contradiction between the SDP file and transport parameters within a single PATCH request, in all other cases the most recently received PATCH request takes priority.

Unicast

v=0
o=- 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Example
c=IN IP4 10.46.16.34/127
t=2873397496 2873404696
a=recvonly
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

"transport_params": [
    {
        "source_ip": null,
        "multicast_ip": null,
        "interface_ip": "10.46.16.34",
        "destination_port": 51372,
        "rtp_enabled": true
    }
]

Source Specific Multicast

v=0
o=- 1497010742 1497010742 IN IP4 172.29.26.24
s=SDP Example
t=2873397496 2873404696
m=video 5000 RTP/AVP 103
c=IN IP4 232.21.21.133/32
a=source-filter:incl IN IP4 232.21.21.133 172.29.226.24
a=rtpmap:103 raw/90000

"transport_params": [
    {
        "source_ip": "172.29.226.24",
        "multicast_ip": "232.21.21.133",
        "interface_ip": "auto",
        "destination_port": 5000,
        "rtp_enabled": true
    }
]

Any Source Multicast

v=0
o=- 1497010742 1497010742 IN IP4 172.29.26.24
s=SDP Example
t=2873397496 2873404696
m=video 5000 RTP/AVP 103
c=IN IP4 239.21.21.133/32
a=rtpmap:103 raw/90000

"transport_params": [
    {
        "source_ip": null,
        "multicast_ip": "239.21.21.133",
        "interface_ip": "auto",
        "destination_port": 5000,
        "rtp_enabled": true
    }
]

Operation with SMPTE 2022-5

SMPTE 2022-5 describes RTP streams with forward error correction (FEC), and is supported by the Connection Management Specification. This support takes the form of the FEC transport parameter set described in Parameter Sets. Note that Senders have additional parameters used to specify the type of FEC to be used and matrix rows and columns, which are not present on the Receiver side. In SMPTE 2022-5 this information is conveyed in the FEC stream headers, and as such does not need to be conveyed separately in Connection Management.

Connection Management APIs supporting SMPTE 2022-5 must comply with RFC 6364 when creating and interpreting SDP files. Implementers may wish to consider the guidance given in VSF TR-04. An example SDP file from RFC 6364 is shown below, followed by the transport parameters that would be presented on the /staged endpoint by a Receiver that has parsed the file.

v=0
o=ali 1122334455 1122334466 IN IP4 172.29.26.24
s=FEC Framework Examples
t=0 0
a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=10; ss-fssi=n:7,k:5
a=mid:R1

"transport_params": [
    {
        "source_ip": null,
        "multicast_ip": "233.252.0.1",
        "interface_ip": "auto",
        "destination_port": 30000,
        "rtp_enabled": true,
        "fec_enable": true,
        "fec_mode": "auto",
        "fec1D_destination_port": 30000,
        "fec2D_destination_port": null,
        "fec_destination_ip": "233.252.0.2"
    }
]

Operation with SMPTE 2022-7

SMPTE 2022-7 describes redundant streams for RTP connections, and is supported by the Connection Management Specification. This manifests itself in the fact that the JSON which describes constraints and transport parameters resides within an array. Where SMPTE-2022-7 is not supported this array contains only one object. Where SMPTE-2022-7 is supported the array contains two entries. The first entry contains information pertaining to Path 1, the second information pertaining to Path 2.

Where a Receiver supports SMPTE 2022-7 but receives a request with a non-SMPTE 2022-7 transport file, the Receiver should set rtp_enabled in the second set of parameters to false and transport parameters in the SDP file should be mapped onto that first set of parameters in the array with rtp_enabled set to true (bearing in mind that the transport_params values in the same request take priority).

Where a client request does not include a transport file and uses only transport_params to configure such a Receiver for a non-SMPTE 2022-7 stream, the request should explicitly set rtp_enabled in the second set of parameters to false.

Where a Receiver does not support SMPTE 2022-7 but receives a SMPTE 2022-7 transport file containing two sets of transport parameters it is recommended that it parses the first set of transport parameters found in the file and joins the stream as if it were a non-SMPTE 2022-7 stream. This ensures compatibility with Senders which do not support operation in a non-SMPTE 2022-7 mode.

In all cases, if a client request includes transport_params, it must have the same number of array elements (or ‘legs’) as specified in the constraints. If no changes are required to a specific leg it must be included as an empty object ({}).

Connection Management APIs supporting SMPTE 2022-7 must comply with RFC 7104 when creating and interpreting SDP files. Implementers may also wish to consider the guidance given in VSF TR-04. The stream listed first in the SDP file should be interpreted as being Path 1, and be populated to the first transport parameter object in /staged, with the inverse being true for Path 2.

The three examples given in RFC 7104 are shown below, followed by the transport parameters that would be presented on the /staged endpoint by a Receiver that has parsed the file.

Separate Source Addresses

v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 198.51.100.2
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1010 cname:ch1@example.com
a=ssrc-group:DUP 1000 1010
a=mid:Ch1

"transport_params": [
    {
        "source_ip": "198.51.100.1",
        "multicast_ip": "233.252.0.1",
        "interface_ip": "auto",
        "destination_port": 30000,
        "rtp_enabled": true
    }, {
        "source_ip": "198.51.100.2",
        "multicast_ip": "233.252.0.1",
        "interface_ip": "auto",
        "destination_port": 30000,
        "rtp_enabled": true
    }
]

Separate Destination Addresses

v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=mid:S1b

"transport_params": [
    {
        "source_ip": "198.51.100.1",
        "multicast_ip": "233.252.0.1",
        "interface_ip": "auto",
        "destination_port": 30000,
        "rtp_enabled": true
    }, {
        "source_ip": "198.51.100.1",
        "multicast_ip": "233.252.0.2",
        "interface_ip": "auto",
        "destination_port": 30000,
        "rtp_enabled": true
    }
]

Temporal Redundancy

v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:50
a=mid:Ch1

"transport_params": [
    {
        "source_ip": "198.51.100.1",
        "multicast_ip": "233.252.0.1",
        "interface_ip": "auto",
        "destination_port": 30000,
        "rtp_enabled": true
    }, {
        "source_ip": "198.51.100.1",
        "multicast_ip": "233.252.0.1",
        "interface_ip": "auto",
        "destination_port": 30000,
        "rtp_enabled": true
    }
]

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 the next highest odd port after the RTP port should be 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.

Senders and Receivers supporting RTCP should comply with RFC 3605 when creating and receiving SDP files. An RFC 3605 compliant SDP files are shown below, along with the transport parameters that would be presented on the /staged endpoint by a Receiver that had just parsed that file.

v=0
o=- 1497010742 1497010742 IN IP4 172.29.26.24
s=SDP Example
t=2873397496 2873404696
m=video 5000 RTP/AVP 103
c=IN IP4 232.21.21.133/32
a=source-filter:incl IN IP4 232.21.21.133 172.29.226.24
a=rtpmap:103 raw/90000
a=rtcp:5001 IN IP4 232.21.21.133

"transport_params": [
    {
        "source_ip": "172.29.226.24",
        "multicast_ip": "232.21.21.133",
        "interface_ip": "auto",
        "destination_port": 5000,
        "rtcp_enabled": true,
        "rtcp_destination_ip": "232.21.21.133",
        "rtcp_destination_port": 5001,
        "rtp_enabled": true
    }
]

←Behaviour · Index↑ · Upgrade Path→

Documentation built at 03:28:53 CDT on 2024-09-11.
(c) AMWA 2024. RAML/JSON licensed under Apache 2.0. Documentation licensed under CC BY-ND 4.0.