draft-ietf-avtext-splicing-notification-09.txt | rfc8286.txt | |||
---|---|---|---|---|
AVTEXT Working Group J. Xia | Internet Engineering Task Force (IETF) J. Xia | |||
INTERNET-DRAFT R. Even | Request for Comments: 8286 R. Even | |||
Intended Status: Standards Track R. Huang | Category: Standards Track R. Huang | |||
Expires: February 4, 2017 Huawei | ISSN: 2070-1721 Huawei | |||
L. Deng | L. Deng | |||
China Mobile | China Mobile | |||
August 3, 2016 | October 2017 | |||
RTP/RTCP extension for RTP Splicing Notification | RTP/RTCP Extension for RTP Splicing Notification | |||
draft-ietf-avtext-splicing-notification-09 | ||||
Abstract | Abstract | |||
Content splicing is a process that replaces the content of a main | Content splicing is a process that replaces the content of a main | |||
multimedia stream with other multimedia content, and delivers the | multimedia stream with other multimedia content and that delivers the | |||
substitutive multimedia content to the receivers for a period of | substitutive multimedia content to the receivers for a period of | |||
time. The splicer is designed to handle RTP splicing and needs to | time. The splicer is designed to handle RTP splicing and needs to | |||
know when to start and end the splicing. | know when to start and end the splicing. | |||
This memo defines two RTP/RTCP extensions to indicate the splicing | This memo defines two RTP/RTCP extensions to indicate the splicing- | |||
related information to the splicer: an RTP header extension that | related information to the splicer: an RTP header extension that | |||
conveys the information in-band and an RTCP packet that conveys the | conveys the information "in band" and an RTP Control Protocol (RTCP) | |||
information out-of-band. | packet that conveys the information out of band. | |||
Status of this Memo | ||||
This Internet-Draft is submitted to IETF in full conformance with the | ||||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | Status of This Memo | |||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as | ||||
Internet-Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This is an Internet Standards Track document. | |||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | This document is a product of the Internet Engineering Task Force | |||
http://www.ietf.org/1id-abstracts.html | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by the | ||||
Internet Engineering Steering Group (IESG). Further information on | ||||
Internet Standards is available in Section 2 of RFC 7841. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | Information about the current status of this document, any errata, | |||
http://www.ietf.org/shadow.html | and how to provide feedback on it may be obtained at | |||
https://www.rfc-editor.org/info/rfc8286. | ||||
Copyright and License Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction ....................................................3 | |||
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology ................................................3 | |||
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Overview ........................................................4 | |||
2.1 Overview of RTP Splicing . . . . . . . . . . . . . . . . . . 4 | 2.1. Overview of RTP Splicing ...................................4 | |||
2.2 Overview of Splicing Interval . . . . . . . . . . . . . . . 5 | 2.2. Overview of Splicing Interval ..............................5 | |||
3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 | 3. Conveying Splicing Interval in RTP/RTCP Extensions ..............7 | |||
3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5 | 3.1. RTP Header Extension .......................................7 | |||
3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 | 3.2. RTCP Splicing Notification Message .........................8 | |||
4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 | 4. Reducing Splicing Latency ......................................10 | |||
5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5. Failure Cases ..................................................11 | |||
6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 6. Session Description Protocol (SDP) Signaling ...................12 | |||
6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9 | 6.1. Declarative SDP ...........................................12 | |||
6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9 | 6.2. Offer/Answer without BUNDLE ...............................13 | |||
6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10 | 6.3. Offer/Answer with BUNDLE: All Media Are Spliced ...........14 | |||
6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12 | 6.4. Offer/Answer with BUNDLE: A Subset of Media Are Spliced ...16 | |||
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 | 7. Security Considerations ........................................18 | |||
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 | 8. IANA Considerations ............................................19 | |||
8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 14 | 8.1. RTCP Control Packet Types .................................19 | |||
8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 14 | 8.2. RTP Compact Header Extensions .............................20 | |||
8.3 SDP Grouping Semantic Extension . . . . . . . . . . . . . . 14 | 8.3. SDP Grouping Semantic Extension ...........................20 | |||
9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. References .....................................................20 | |||
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9.1. Normative References ......................................20 | |||
10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 | 9.2. Informative References ....................................21 | |||
10.2 Informative References . . . . . . . . . . . . . . . . . . 15 | Acknowledgements ..................................................22 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | Authors' Addresses ................................................22 | |||
1 Introduction | 1. Introduction | |||
Splicing is a process that replaces some multimedia content with | Splicing is a process that replaces some multimedia content with | |||
other multimedia content and delivers the substitutive multimedia | other multimedia content and delivers the substitutive multimedia | |||
content to the receivers for a period of time. In some predictable | content to the receivers for a period of time. In some predictable | |||
splicing cases, e.g., advertisement insertion, the splicing duration | splicing cases, e.g., advertisement insertion, the splicing duration | |||
needs to be inside of the specific, pre-designated time slot. Certain | needs to be inside of the specific pre-designated time slot. Certain | |||
timing information about when to start and end the splicing must be | timing information about when to start and end the splicing must be | |||
first acquired by the splicer in order to start the splicing. This | first acquired by the splicer in order to start the splicing. This | |||
document refers to this information as the Splicing Interval. | document refers to this information as the "Splicing Interval". | |||
[SCTE35] provides a method that encapsulates the Splicing Interval | [SCTE35] provides a method that encapsulates the Splicing Interval | |||
inside the MPEG2-TS layer in cable TV systems. When transported in | inside the MPEG2-TS (MPEG2 transport stream) layer in cable TV | |||
RTP, an middle box designed as the splicer to decode the RTP packets | systems. When transported in RTP, a middlebox designed as the | |||
and search for the Splicing Interval inside the payloads is required. | splicer to decode the RTP packets and search for the Splicing | |||
The need for such processing increases the workload of the middle box | Interval inside the payloads is required. The need for such | |||
and limits the number of RTP sessions the middle box can support. | processing increases the workload of the middlebox and limits the | |||
number of RTP sessions the middlebox can support. | ||||
The document defines an RTP header extension [RFC5285bis] used by the | This document defines an RTP header extension [RFC8285] used by the | |||
main RTP sender to provide the Splicing Interval by including it in | main RTP sender to provide the Splicing Interval by including it in | |||
the RTP packets. | the RTP packets. | |||
However, the Splicing Interval conveyed in the RTP header extension | However, the Splicing Interval conveyed in the RTP header extension | |||
might not reach the splicer successfully. Any splicing un-aware | might not reach the splicer successfully. Any splicing-unaware | |||
middlebox on the path between the RTP sender might strip this RTP | middlebox on the path between the RTP sender and the splicer might | |||
header extension. | strip this RTP header extension. | |||
To increase robustness against such case, the document also defines a | To increase robustness against such a case, this document also | |||
new RTCP packet type to carry the same Splicing Interval to the | defines a new RTP Control Protocol (RTCP) packet type to carry the | |||
splicer. Since RTCP is also unreliable and may not be so immediate as | same Splicing Interval to the splicer. Since RTCP is also unreliable | |||
the in-band way, it's only considered as a complement to the RTP | and may not be as "immediate" as the in-band technique, it's only | |||
header extension. | considered to be a complement to the RTP header extension. | |||
1.1 Terminology | 1.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
In addition, we define following terminologies: | In addition, we define the following terms: | |||
Main RTP sender: | Main RTP Sender: | |||
The sender of RTP packets carrying the main RTP stream. | The sender of RTP packets carrying the main RTP stream. | |||
Splicer: | Splicer: | |||
An intermediary node that inserts substitutive content into a main | An intermediary node that inserts substitutive content into a main | |||
RTP stream. The splicer sends substitutive content to the RTP | RTP stream. The splicer sends substitutive content to the RTP | |||
receiver instead of the main content during splicing. It is also | receiver instead of the main content during splicing. It is also | |||
responsible for processing RTCP traffic between the RTP sender and | responsible for processing RTCP traffic between the RTP sender and | |||
the RTP receiver. | the RTP receiver. | |||
Splicing-In Point | Splicing-In Point: | |||
A virtual point in the RTP stream, suitable for substitutive | A virtual point in the RTP stream, suitable for substitutive | |||
content entry, typically in the boundary between two independently | content entry, typically in the boundary between two independently | |||
decodable frames. | decodable frames. | |||
Splicing-Out Point | Splicing-Out Point: | |||
A virtual point in the RTP stream, suitable for substitutive | A virtual point in the RTP stream, suitable for substitutive | |||
content exit, typically in the boundary between two independently | content exit, typically in the boundary between two independently | |||
decodable frames. | decodable frames. | |||
Splicing Interval: | Splicing Interval: | |||
The NTP-format timestamps, representing the main RTP sender | The NTP timestamps, representing the main RTP sender wallclock | |||
wallclock time, for the Splicing-In point and Splicing-Out point | time, for the splicing-in point and splicing-out point per | |||
per [RFC6828] allowing the splicer to know when to start and end | [RFC6828], allowing the splicer to know when to start and end the | |||
the RTP splicing. | RTP splicing. | |||
Substitutive RTP Sender: | Substitutive RTP Sender: | |||
The sender of RTP packets carrying the RTP stream that will | The sender of RTP packets carrying the RTP stream that will | |||
replace the content in the main RTP stream. | replace the content in the main RTP stream. | |||
2 Overview | 2. Overview | |||
2.1 Overview of RTP Splicing | 2.1. Overview of RTP Splicing | |||
RTP Splicing is intended to replace some multimedia content with | RTP splicing is intended to replace some multimedia content with | |||
certain substitutive multimedia content, and then forward it to the | certain substitutive multimedia content and then forward it to the | |||
receivers for a period of time. This process is authorized by the | receivers for a period of time. This process is authorized by the | |||
main RTP sender that offers a specific time window for inserting the | main RTP sender that offers a specific time window for inserting the | |||
substitutive multimedia content in the main content. A typical usage | substitutive multimedia content in the main content. A typical usage | |||
is that IPTV service provider uses its own regional advertising | scenario is where an IPTV service provider uses its own regional | |||
content to replace national advertising content, the time window of | advertising content to replace national advertising content, the time | |||
which is explicitly indicated by the IPTV service provider. | window of which is explicitly indicated by the IPTV service provider. | |||
The splicer is a middlebox handling RTP splicing. It receives main | The splicer is a middlebox handling RTP splicing. It receives the | |||
content and substitutive content simultaneously but only chooses to | main content and substitutive content simultaneously but only chooses | |||
send one of them to the receiver at any point of time. When RTP | to send one of them to the receiver at any point in time. When RTP | |||
splicing begins, the splicer sends the substitutive content to the | splicing begins, the splicer sends the substitutive content to the | |||
receivers instead of the main content. When RTP splicing ends, the | receivers instead of the main content. When RTP splicing ends, the | |||
splicer switches back to sending the main content to the receivers. | splicer switches back to sending the main content to the receivers. | |||
This implies that the receiver is explicitly configured to receive | This implies that the receiver is explicitly configured to receive | |||
the traffic via the splicer, and will return any RTCP feedback to it | the traffic via the splicer and will return any RTCP feedback to it | |||
in the presence of the splicer. | in the presence of the splicer. | |||
The middlebox working as the splicer can be implemented as either an | The middlebox working as the splicer can be implemented as either an | |||
RTP mixer or as an RTP translator. If implemented as an RTP mixer, | RTP mixer or an RTP translator. If implemented as an RTP mixer, the | |||
the splicer will use its own SSRC, sequence number space, and timing | splicer will use its own synchronization source (SSRC), sequence | |||
model when generating the output stream to receivers, using the CSRC | number space, and timing model when generating the output stream to | |||
list to indicate whether the original or substitutive content is | receivers, using the contributing source (CSRC) list to indicate | |||
being delivered. The splicer, on behalf of the content provider, can | whether the original content or substitutive content is being | |||
omit the CSRC list from the RTP packets it generates. This simplifies | delivered. The splicer, on behalf of the content provider, can omit | |||
the design of the receivers, since they don't need to parse the CSRC | the CSRC list from the RTP packets it generates. This simplifies the | |||
design of the receivers, since they don't need to parse the CSRC | ||||
list, but makes it harder to determine when the splicing is taking | list, but makes it harder to determine when the splicing is taking | |||
place (it requires inspection of the RTP payload data, rather than | place (it requires inspection of the RTP payload data, rather than | |||
just the RTP headers). A splicer working as an RTP mixer splits the | just the RTP headers). A splicer working as an RTP mixer splits the | |||
flow between the sender and receiver into two, and requires separate | flow between the sender and receiver into two, and it requires | |||
control loops, for RTCP and congestion control. [RFC6828] offers an | separate control loops for RTCP and congestion control. [RFC6828] | |||
example of an RTP mixer approach. | provides an example of an RTP mixer approach. | |||
A splicer implemented as an RTP translator [RFC3550] will forward the | A splicer implemented as an RTP translator [RFC3550] will forward the | |||
RTP packets from the original and substitutive senders with their | RTP packets from the original and substitutive senders with their | |||
SSRCs intact, but will need to rewrite RTCP sender report packets to | SSRCs intact but will need to rewrite RTCP Sender Report (SR) packets | |||
account for the splicing. In this case, the congestion control loops | to account for the splicing. In this case, the congestion control | |||
run between original sender and receiver, and between the | loops run between the original sender and receiver and between the | |||
substitutive sender and receiver. The splicer needs to ensure that | substitutive sender and receiver. The splicer needs to ensure that | |||
the RTCP feedback message from the receiver are passed to the right | the RTCP feedback messages from the receiver are passed to the right | |||
sender to let the congestion control work. | sender to let the congestion control work. | |||
2.2 Overview of Splicing Interval | 2.2. Overview of Splicing Interval | |||
To handle splicing on the RTP layer at the reserved time slots set by | To handle splicing on the RTP layer at the reserved time slots set by | |||
the main RTP sender, the splicer must first know the Splicing | the main RTP sender, the splicer must first know the Splicing | |||
Interval from the main RTP sender before it can start splicing. | Interval from the main RTP sender before it can start splicing. | |||
When a new splicing is forthcoming, the main RTP sender needs to send | When a new splicing is forthcoming, the main RTP sender needs to send | |||
the Splicing Interval to the splicer. The Splicing Interval SHOULD be | the Splicing Interval to the splicer. The Splicing Interval SHOULD | |||
sent by RTP header extension or RTCP extension message more than once | be sent by the RTP header extension or RTCP extension message more | |||
to mitigate the possible packet loss. To enable the splicer to get | than once to mitigate possible packet loss. To enable the splicer to | |||
the substitutive content before the splicing starts, the main RTP | get the substitutive content before the splicing starts, the main RTP | |||
sender MUST send the Splicing Interval far ahead. For example, the | sender MUST send the Splicing Interval well in advance. For example, | |||
main RTP sender can estimate when to send the Splicing Interval based | the main RTP sender can estimate when to send the Splicing Interval | |||
on the round-trip time (RTT) following the mechanisms in section | based on the round-trip time (RTT), following the mechanisms | |||
6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender. | described in Section 6.4.1 of [RFC3550] when the splicer sends an | |||
RTCP Receiver Report (RR) to the main sender. | ||||
The substitutive sender also needs to learn the Splicing Interval | The substitutive sender also needs to learn the Splicing Interval | |||
from the main RTP sender in advance, and thus estimates when to | from the main RTP sender in advance and estimate when to transfer the | |||
transfer the substitutive content to the splicer. The Splicing | substitutive content to the splicer. The Splicing Interval could be | |||
Interval could be transmitted from the main RTP sender to the | transmitted from the main RTP sender to the substitutive content | |||
substitutive content using some out-of-band mechanisms, for example, | using some out-of-band mechanisms -- for example, a proprietary | |||
a proprietary mechanism to exchange the Splicing Interval, or the | mechanism to exchange the Splicing Interval -- or the substitutive | |||
substitutive sender is implemented together with the main RTP sender | sender is implemented together with the main RTP sender inside a | |||
inside a single device. To ensure the Splicing Interval is valid for | single device. To ensure that the Splicing Interval is valid for | |||
both the main RTP sender and the substitutive RTP sender, the two | both the main RTP sender and the substitutive RTP sender, the two | |||
senders MUST share a common reference clock so that the splicer can | senders MUST share a common reference clock so that the splicer can | |||
achieve accurate splicing. The requirements for the common reference | achieve accurate splicing. The requirements for the common reference | |||
clock (e.g. resolution, skew) depend on the codec used by the media | clock (e.g., resolution, skew) depend on the codec used by the media | |||
content. | content. | |||
In this document, the main RTP sender uses a pair of NTP-format | In this document, the main RTP sender uses a pair of NTP timestamps | |||
timestamps, to indicate when to start and end the splicing to the | to indicate when to start and end the splicing to the splicer: the | |||
splicer: the timestamp of the first substitutive RTP packet at the | timestamp of the first substitutive RTP packet at the splicing-in | |||
splicing in point, and the timestamp of the first main RTP packet at | point and the timestamp of the first main RTP packet at the | |||
the splicing out point. | splicing-out point. | |||
When the substitutive RTP sender gets the Splicing Interval, it must | When the substitutive RTP sender gets the Splicing Interval, it must | |||
prepare the substitutive stream. The main and the substitutive | prepare the substitutive stream. The main content provider and the | |||
content providers MUST ensure that the RTP timestamp of the first | substitutive content provider MUST ensure that the RTP timestamp of | |||
substitutive RTP packet that would be presented to the receivers | the first substitutive RTP packet that would be presented to the | |||
corresponds to the same time instant as the former NTP-format | receivers corresponds to the same time instant as the former | |||
timestamp in the Splicing Interval. To enable the splicer to know the | NTP timestamp in the Splicing Interval. To enable the splicer to | |||
first substitutive RTP packet it needs to send, the substitutive RTP | know the first substitutive RTP packet it needs to send, the | |||
sender MUST send the substitutive RTP packet ahead of the Splicing In | substitutive RTP sender MUST send the substitutive RTP packet ahead | |||
point, allowing the splicer to find out the timestamp of this first | of the splicing-in point, allowing the splicer to find out the | |||
RTP packet in the substitutive RTP stream, e.g., using a prior RTCP | timestamp of this first RTP packet in the substitutive RTP stream, | |||
SR (Sender Report) message. | e.g., using a prior RTCP SR message. | |||
When the splicing will end, the main content provider and the | When it is time for the splicing to end, the main content provider | |||
substitutive content provider MUST ensure the RTP timestamp of the | and the substitutive content provider MUST ensure that the RTP | |||
first main RTP packet that would be presented on the receivers | timestamp of the first main RTP packet that would be presented on the | |||
corresponds to the same time instant as the latter NTP-format | receivers corresponds to the same time instant as the latter | |||
timestamp in the Splicing Interval. | NTP timestamp in the Splicing Interval. | |||
3 Conveying Splicing Interval in RTP/RTCP extensions | 3. Conveying Splicing Interval in RTP/RTCP Extensions | |||
This memo defines two backwards compatible RTP extensions to convey | This memo defines two backward-compatible RTP extensions to convey | |||
the Splicing Interval to the splicer: an RTP header extension and an | the Splicing Interval to the splicer: an RTP header extension and an | |||
RTCP splicing notification message. | RTCP splicing notification message. | |||
3.1 RTP Header Extension | 3.1. RTP Header Extension | |||
The RTP header extension mechanism defined in [RFC5285bis] can be | The RTP header extension mechanism defined in [RFC8285] can be | |||
adapted to carry the Splicing Interval consisting of a pair of NTP- | adapted to carry the Splicing Interval, which consists of a pair of | |||
format timestamps. | NTP timestamps. | |||
This RTP header extension carries the 7 octets splicing-out NTP- | This RTP header extension carries the 7 octets of the splicing-out | |||
format timestamp (lower 24-bit part of the Seconds of a NTP-format | NTP timestamp (lower 24-bit part of the "Seconds" of an NTP timestamp | |||
timestamp and the 32 bits of the Fraction of a NTP-format timestamp | and the 32 bits of the "Fraction" of an NTP timestamp as defined in | |||
as defined in [RFC5905]), followed by the 8 octets splicing-in NTP- | [RFC5905]), followed by the 8 octets of the splicing-in NTP timestamp | |||
format timestamp (64-bit NTP-format timestamp as defined in | (64-bit NTP timestamp as defined in [RFC5905]). The top 8 bits of | |||
[RFC5905]). The top 8 bits of the splicing-out NTP timestamp are | the splicing-out NTP timestamp are inferred from the top 8 bits of | |||
inferred from the top 8 bits of the splicing-in NTP timestamp, under | the splicing-in NTP timestamp, assuming that (1) the splicing-out | |||
the assumption that the splicing-out time is after the splicing-in | time is after the splicing-in time and (2) the Splicing Interval is | |||
time, and the splicing interval is less than 2^25 seconds. Therefore, | less than 2^25 seconds. Therefore, if the value of the 7 octets of | |||
if the value of 7 octets splicing-out NTP-format timestamp is smaller | the splicing-out NTP timestamp is smaller than the value of the | |||
than the value of 7 lower octets splicing-in NTP-format, it implies a | 7 lower octets of the splicing-in NTP timestamp, it implies a wrap of | |||
wrap of the 56-bit splicing-out NTP-format timestamp which means the | the 56-bit splicing-out NTP timestamp, which means that the top 8-bit | |||
top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit | value of the 64-bit splicing-out NTP timestamp is equal to the top | |||
value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 | 8-bit value of the splicing-in NTP timestamp plus 0x01. Otherwise, | |||
bits of splicing-out NTP timestamp is equal to the top 8 bits of | the top 8 bits of the splicing-out NTP timestamp are equal to the top | |||
splicing-in NTP Timestamp. | 8 bits of the splicing-in NTP timestamp. | |||
This RTP header extension can be encoded using either the one-byte or | This RTP header extension can be encoded using either the one-byte or | |||
two-byte header defined in [RFC5285bis]. Figure 1 and 2 show the | two-byte header defined in [RFC8285]. Figures 1 and 2 show the | |||
splicing interval header extension with each of the two header | Splicing Interval header extension with each of the two header | |||
formats. | formats. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | |||
| ID | L=14 | OUT NTP timestamp format - Seconds (bit 8-31) |x | | ID | L=14 | OUT NTP timestamp - Seconds (bit 8-31) |x | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | |||
| OUT NTP timestamp format - Fraction (bit 0-31) |e | | OUT NTP timestamp - Fraction (bit 0-31) |e | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | |||
| IN NTP timestamp format - Seconds (bit 0-31) |s | | IN NTP timestamp - Seconds (bit 0-31) |s | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | |||
| IN NTP timestamp format - Fraction (bit 0-31) |o | | IN NTP timestamp - Fraction (bit 0-31) |o | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | |||
Figure 1: Splicing Interval | Figure 1: Splicing Interval Using the One-Byte Header Format | |||
Using the One-Byte Header Format | ||||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | |||
| ID | L=15 | OUT NTP timestamp - Seconds |x | | ID | L=15 | OUT NTP timestamp - Seconds |x | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | |||
|Out Secds(cont)| OUT NTP timestamp format - Fraction |e | |OUT Secds(cont)| OUT NTP timestamp - Fraction |e | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | |||
|Out Fract(cont)| IN NTP timestamp format - Seconds |s | |OUT Fract(cont)| IN NTP timestamp - Seconds |s | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | |||
| In Secds(cont)| IN NTP timestamp format - Fraction |o | | IN Secds(cont)| IN NTP timestamp - Fraction |o | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | |||
| In Fract(cont)| 0 (pad) | ... | | IN Fract(cont)| 0 (pad) | ... | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: Splicing Interval | Figure 2: Splicing Interval Using the Two-Byte Header Format | |||
Using the Two-Byte Header Format | ||||
Since the inclusion of an RTP header extension will reduce the | Since the inclusion of an RTP header extension will reduce the | |||
efficiency of RTP header compression, it is RECOMMENDED that the main | efficiency of RTP header compression, it is RECOMMENDED that the main | |||
sender inserts the RTP header extensions into only a number of RTP | sender insert the RTP header extensions into a number of RTP packets, | |||
packets, instead of all the RTP packets, prior to the splicing in. | instead of all of the RTP packets, prior to the splicing-in. | |||
After the splicer obtains the RTP header extension and derives the | After the splicer obtains the RTP header extension and derives the | |||
Splicing Interval, it generates its own stream and is not allowed to | Splicing Interval, it generates its own stream and is not allowed to | |||
include the RTP header extension in outgoing packets to reduce header | include the RTP header extension in outgoing packets; this reduces | |||
overhead. | header overhead. | |||
3.2 RTCP Splicing Notification Message | 3.2. RTCP Splicing Notification Message | |||
In addition to the RTP header extension, the main RTP sender includes | In addition to including the RTP header extension, the main RTP | |||
the Splicing Interval in an RTCP splicing notification message. | sender includes the Splicing Interval in an RTCP splicing | |||
Whether or not the timestamps are included in the RTP header | notification message. Whether or not the timestamps are included in | |||
extension, the main RTP sender MUST send the RTCP splicing | the RTP header extension, the main RTP sender MUST send the RTCP | |||
notification message. This provide robustness in the case where a | splicing notification message. This provides robustness in the case | |||
middlebox strips RTP header extensions. The main RTP sender MUST make | where a middlebox strips RTP header extensions. The main RTP sender | |||
sure the splicing information contained in the RTCP splicing | MUST make sure that the splicing information contained in the RTCP | |||
notification message consistent with the information included in the | splicing notification message is consistent with the information | |||
RTP header extensions. | included in the RTP header extensions. | |||
The RTCP splicing notification message is a new RTCP packet type. It | The RTCP splicing notification message is a new RTCP packet type. It | |||
has a fixed header followed by a pair of NTP-format timestamps: | has a fixed header followed by a pair of NTP timestamps: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|V=2|P|reserved | PT=TBA | length | | |V=2|P|reserved | PT=213 | length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SSRC | | | SSRC | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IN NTP Timestamp (most significant word) | | | IN NTP timestamp (most significant word) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IN NTP Timestamp (least significant word) | | | IN NTP timestamp (least significant word) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| OUT NTP Timestamp (most significant word) | | | OUT NTP timestamp (most significant word) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| OUT NTP Timestamp (least significant word) | | | OUT NTP timestamp (least significant word) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: RTCP Splicing Notification Message | Figure 3: RTCP Splicing Notification Message | |||
The RSI packet includes the following fields: | The RTCP splicing notification message includes the following fields: | |||
Length: 16 bits | Length: 16 bits | |||
As defined in [RFC3550], the length of the RTCP packet in 32-bit | As defined in [RFC3550], the length of the RTCP packet in 32-bit | |||
words minus one, including the header and any padding. | words minus one, including the header and any padding. | |||
SSRC: 32 bits | SSRC: 32 bits | |||
The SSRC of the Main RTP Sender. | The SSRC of the main RTP sender. | |||
Timestamp: 64 bits | Timestamp: 64 bits | |||
Indicates the wallclock time when this splicing starts and ends. | Indicates the wallclock time when this splicing starts and ends. | |||
The full-resolution NTP-format timestamp is used, which is a 64- | The full-resolution NTP timestamp is used, which is a 64-bit | |||
bit, unsigned, fixed-point number with the integer part in the | unsigned fixed-point number with the integer part in the first | |||
first 32 bits and the fractional part in the last 32 bits. This | 32 bits and the fractional part in the last 32 bits. This format | |||
format is same as the NTP timestamp field in the RTCP Sender | is the same as the NTP timestamp field in the RTCP SR | |||
Report (Section 6.4.1 of [RFC3550]). | (Section 6.4.1 of [RFC3550]). | |||
The RTCP splicing notification message can be included in the RTCP | The RTCP splicing notification message can be included in the RTCP | |||
compound packet together with RTCP SR generated at the main RTP | compound packet together with the RTCP SR generated at the main RTP | |||
sender, and hence follows the compound RTCP rules defined in Section | sender; hence, it follows the compound RTCP rules defined in | |||
6.1 in [RFC3550]. | Section 6.1 in [RFC3550]. | |||
If the use of non-compound RTCP [RFC5506] was previously negotiated | If the use of non-compound RTCP [RFC5506] was previously negotiated | |||
between the sender and the splicer, the RTCP splicing notification | between the sender and the splicer, the RTCP splicing notification | |||
message may be sent as non-compound RTCP packets. In some cases that | messages may be sent as non-compound RTCP packets. In some cases | |||
the mapping from RTP timestamp to NTP timestamp changes, e.g., clock | where the mapping from the RTP timestamp to the NTP timestamp | |||
drift happening before the splicing event, it may be required to send | changes, e.g., clock drift happens before the splicing event, sending | |||
RTCP SR or even updated Splicing Interval information timely to | an RTCP SR or even updated Splicing Interval information in a timely | |||
update the timestamp mapping for accurate splicing. | manner might be required in order to update the timestamp mapping for | |||
accurate splicing. | ||||
Since the RTCP splicing notification message is intentionally sent by | Since the RTCP splicing notification message is intentionally sent by | |||
the main RTP sender to the splicer, the splicer is not allowed to | the main RTP sender to the splicer, the splicer is not allowed to | |||
forward this message to the receivers so as to avoid their useless | forward this message to the receivers, so as to avoid useless | |||
processing and additional RTCP bandwidth consumption in the | processing and additional RTCP bandwidth consumption in the | |||
downstream. | downstream receivers. | |||
4 Reducing Splicing Latency | 4. Reducing Splicing Latency | |||
When splicing starts or ends, the splicer outputs the multimedia | When splicing starts or ends, the splicer outputs the multimedia | |||
content from another sender to the receivers. Given that the | content from another sender to the receivers. Given that the | |||
receivers must first acquire certain information ([RFC6285] refers to | receivers must first acquire certain information ([RFC6285] refers to | |||
this information as Reference Information) to start processing the | this information as "Reference Information") to start processing the | |||
multimedia data, either the main RTP sender or the substitutive | multimedia data, either the main RTP sender or the substitutive | |||
sender SHOULD provide the Reference Information together with its | sender SHOULD provide the Reference Information together with its | |||
multimedia content to reduce the delay caused by acquiring the | multimedia content to reduce the delay caused by acquiring the | |||
Reference Information. The methods by which the Reference Information | Reference Information. The methods by which the Reference | |||
is distributed to the receivers is out of scope of this memo. | Information is distributed to the receivers are out of scope for | |||
this memo. | ||||
Another latency element is synchronization caused delay. The | Another latency element is delay caused by synchronization. The | |||
receivers must receive enough synchronization metadata prior to | receivers must receive enough synchronization metadata prior to | |||
synchronizing the separate components of the multimedia streams when | synchronizing the separate components of the multimedia streams when | |||
splicing starts or ends. Either the main RTP sender or the | splicing starts or ends. Either the main RTP sender or the | |||
substitutive sender SHOULD send the synchronization metadata early | substitutive sender SHOULD send the synchronization metadata early | |||
enough so that the receivers can play out the multimedia in a | enough so that the receivers can play out the multimedia in a | |||
synchronized fashion. The main RTP sender or the substitutive sender | synchronized fashion. The main RTP sender or the substitutive sender | |||
can estimate when to send the synchronization metadata based on, for | can estimate when to send the synchronization metadata based on, for | |||
example, the round-trip time (RTT) following the mechanisms in | example, the RTT, following the mechanisms described in Section 6.4.1 | |||
section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main | of [RFC3550] when the splicer sends an RTCP RR to the main sender or | |||
sender or the substitutive sender. The main RTP sender and the | the substitutive sender. The main RTP sender and the substitutive | |||
substitutive sender can also be coordinated by some proprietary out- | sender can also be coordinated by some proprietary out-of-band | |||
of-band mechanisms to decide when and whom to send the metadata. If | mechanisms to decide when, and to whom, the metadata is to be sent. | |||
both send the information, the splicer SHOULD pick one based on the | If both send the information, the splicer SHOULD pick one based on | |||
current situation, e.g., choosing main RTP sender when synchronizing | the current situation, e.g., choosing either (1) the main RTP sender | |||
the main media content while choosing the information from the | when synchronizing the main media content or (2) the information from | |||
substitutive sender when synchronizing the spliced content. The | the substitutive sender when synchronizing the spliced content. To | |||
mechanisms defined in [RFC6051] are RECOMMENDED to be adopted to | reduce possible synchronization delay, it is RECOMMENDED that the | |||
reduce the possible synchronization delay. | mechanisms defined in [RFC6051] be adopted. | |||
5 Failure Cases | 5. Failure Cases | |||
This section examines the implications of losing RTCP splicing | This section examines the implications of losing RTCP splicing | |||
notification message and the other failure case, e.g., the RTP header | notification messages, e.g., the RTP header extension is stripped on | |||
extension is stripped on the path. | the path. | |||
Given that there may be a splicing un-aware middlebox on the path | Given that there may be a splicing-unaware middlebox on the path | |||
between the main RTP sender and the splicer, the main and the | between the main RTP sender and the splicer, the main and | |||
substitutive RTP senders can use one heuristic to verify whether or | substitutive RTP senders can use one heuristic to verify whether or | |||
not the Splicing Interval reaches the splicer. | not the Splicing Interval reaches the splicer. | |||
The splicer can be implemented to have its own SSRC, and send RTCP | The splicer can be implemented to have its own SSRC and send RTCP | |||
reception reports to the senders of the main and substitutive RTP | reception reports to the senders of the main and substitutive RTP | |||
streams. This allows the senders to detect problems on the path to | streams. This allows the senders to detect problems on the path to | |||
the splicer. Alternatively, it is possible to implement the splicer | the splicer. Alternatively, it is possible to implement the splicer | |||
such that it has no SSRC, and does not send RTCP reports; this | such that it has no SSRC and does not send RTCP reports; this | |||
prevents the senders from being able to monitor the quality to the | prevents the senders from being able to monitor the quality of the | |||
path to the splicer. | path to the splicer. | |||
If the splicer has an SSRC and sends its own RTCP reports, it can | If the splicer has an SSRC and sends its own RTCP reports, it can | |||
choose not to pass RTCP reports it receives from the receivers to the | choose not to pass RTCP reports it receives from the receivers to the | |||
senders. This will stop the senders from being able to monitor the | senders. This will prevent the senders from being able to monitor | |||
quality of the paths from the splicer to the receivers. | the quality of the paths from the splicer to the receivers. | |||
A splicer that has an SSRC can choose to pass RTCP reception reports | A splicer that has an SSRC can choose to pass RTCP reception reports | |||
from the receivers back to the senders, after modifications to | from the receivers back to the senders, after modifications to | |||
account for the splicing. This will allow the senders the monitor the | account for the splicing. This will allow the senders to monitor the | |||
quality of the paths from the splicer to the receivers. A splicer | quality of the paths from the splicer to the receivers. A splicer | |||
that does not have its own SSRC has to forward and translation RTCP | that does not have its own SSRC has to forward and translate RTCP | |||
reports from the receiver, otherwise the senders will not see any | reports from the receiver; otherwise, the senders will not see any | |||
receivers in the RTP session. | receivers in the RTP session. | |||
If the splicer is implemented as a mixer, it will have its own SSRC | If the splicer is implemented as a mixer, it will have its own SSRC, | |||
and will send its own RTCP reports, and will forward translated RTCP | send its own RTCP reports, and forward translated RTCP reports from | |||
reports from the receivers. | the receivers. | |||
Upon the detection of a failure, the splicer can communicate with the | Upon the detection of a failure, the splicer can communicate with the | |||
main sender and the substitutive sender in some out of band signaling | main sender and the substitutive sender via some out-of-band | |||
ways to fall back to the payload specific mechanisms it supports, | signaling technique and fall back to the payload-specific mechanisms | |||
e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon | it supports, e.g., the MPEG2-TS splicing solution defined in | |||
the splicing. | [SCTE35], or just abandon the splicing. | |||
6 Session Description Protocol (SDP) Signaling | 6. Session Description Protocol (SDP) Signaling | |||
This document defines the URI for declaring this header extension in | This document defines the URI for declaring this header extension in | |||
an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing- | an "extmap" attribute to be | |||
interval". | "urn:ietf:params:rtp-hdrext:splicing-interval". | |||
This document extends the standard semantics defined in SDP Grouping | This document extends the standard semantics defined in "The Session | |||
Framework [RFC5888] with a new semantic: SPLICE to represent the | Description Protocol (SDP) Grouping Framework" [RFC5888] with a new | |||
relationship between the main RTP stream and the substitutive RTP | semantic, called "SPLICE", to represent the relationship between the | |||
stream. Only 2 m-lines are allowed in the SPLICE group. The main RTP | main RTP stream and the substitutive RTP stream. Only two "m=" lines | |||
stream is the one with the extended extmap attribute, and the other | are allowed in the SPLICE group. The main RTP stream is the one with | |||
one is substitutive stream. A single m-line MUST NOT be included in | the extended "extmap" attribute, and the other one is the | |||
different SPLICE groups at the same time. The main RTP sender | substitutive stream. A single "m=" line MUST NOT be included in | |||
different SPLICE groups at the same time. The main RTP sender | ||||
provides the information about both main and substitutive sources. | provides the information about both main and substitutive sources. | |||
The extended SDP attribute specified in this document is applicable | The extended SDP attribute specified in this document is applicable | |||
for offer/answer content [RFC3264] and do not affect any rules when | for offer/answer content [RFC3264] and does not affect any rules when | |||
negotiating offer and answer. When used with multiple m-lines, | negotiating offers and answers. When used with multiple "m=" lines, | |||
substitutive RTP MUST be applied only to the RTP packets whose SDP m- | substitutive RTP MUST be applied only to the RTP packets whose SDP | |||
line is in the same group with the substitutive stream using SPLICE | "m=" line is in the same group with the substitutive stream using | |||
and has the extended splicing extmap attribute. This semantic is also | SPLICE and has the extended splicing "extmap" attribute. This | |||
applicable for BUNDLE cases. | semantic is also applicable for BUNDLE cases. | |||
The following examples show how SDP signaling could be used for | The following examples show how SDP signaling could be used for | |||
splicing in different cases. | splicing in different cases. | |||
6.1 Declarative SDP | 6.1. Declarative SDP | |||
v=0 | v=0 | |||
o=xia 1122334455 1122334466 IN IP4 splicing.example.com | o=xia 1122334455 1122334466 IN IP4 splicing.example.com | |||
s=RTP Splicing Example | s=RTP Splicing Example | |||
t=0 0 | t=0 0 | |||
a=group:SPLICE 1 2 | a=group:SPLICE 1 2 | |||
m=video 30000 RTP/AVP 100 | m=video 30000 RTP/AVP 100 | |||
i=Main RTP Stream | i=Main RTP Stream | |||
c=IN IP4 233.252.0.1/127 | c=IN IP4 233.252.0.1/127 | |||
a=rtpmap:100 MP2T/90000 | a=rtpmap:100 MP2T/90000 | |||
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=mid:1 | a=mid:1 | |||
m=video 30002 RTP/AVP 100 | m=video 30002 RTP/AVP 100 | |||
i=Substitutive RTP Stream | i=Substitutive RTP Stream | |||
c=IN IP4 233.252.0.2/127 | c=IN IP4 233.252.0.2/127 | |||
a=sendonly | a=sendonly | |||
a=rtpmap:100 MP2T/90000 | a=rtpmap:100 MP2T/90000 | |||
a=mid:2 | a=mid:2 | |||
Figure 3: Example SDP for a single-channel splicing scenario | Figure 4: Example SDP for a Single-Channel Splicing Scenario | |||
The splicer receiving the SDP message above receives one MPEG2-TS | The splicer receiving the SDP message above receives one MPEG2-TS | |||
stream (payload 100) from the main RTP sender (with multicast | stream (payload 100) from the main RTP sender (with a multicast | |||
destination address of 233.252.0.1) on port 30000, and/or receives | destination address of 233.252.0.1) on port 30000 and/or receives | |||
another MPEG2-TS stream from the substitutive RTP sender (with | another MPEG2-TS stream from the substitutive RTP sender (with a | |||
multicast destination address of 233.252.0.2) on port 30002. But at | multicast destination address of 233.252.0.2) on port 30002. But at | |||
a particular point in time, the splicer only selects one stream and | a particular point in time, the splicer only selects one stream and | |||
outputs the content from the chosen stream to the downstream | outputs the content from the chosen stream to the downstream | |||
receivers. | receivers. | |||
6.2 Offer/Answer without BUNDLE | 6.2. Offer/Answer without BUNDLE | |||
SDP Offer - from main RTP sender | SDP Offer - from the main RTP sender: | |||
v=0 | v=0 | |||
o=xia 1122334455 1122334466 IN IP4 splicing.example.com | o=xia 1122334455 1122334466 IN IP4 splicing.example.com | |||
s=RTP Splicing Example | s=RTP Splicing Example | |||
t=0 0 | t=0 0 | |||
a=group:SPLICE 1 2 | a=group:SPLICE 1 2 | |||
m=video 30000 RTP/AVP 31 100 | m=video 30000 RTP/AVP 31 100 | |||
i=Main RTP Stream | i=Main RTP Stream | |||
c=IN IP4 splicing.example.com | c=IN IP4 splicing.example.com | |||
a=rtpmap:31 H261/90000 | a=rtpmap:31 H261/90000 | |||
a=rtpmap:100 MP2T/90000 | a=rtpmap:100 MP2T/90000 | |||
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=sendonly | a=sendonly | |||
a=mid:1 | a=mid:1 | |||
m=video 40000 RTP/AVP 31 100 | m=video 40000 RTP/AVP 31 100 | |||
i=Substitutive RTP Stream | i=Substitutive RTP Stream | |||
c=IN IP4 substitutive.example.com | c=IN IP4 substitutive.example.com | |||
a=rtpmap:31 H261/90000 | a=rtpmap:31 H261/90000 | |||
a=rtpmap:100 MP2T/90000 | a=rtpmap:100 MP2T/90000 | |||
a=sendonly | a=sendonly | |||
a=mid:2 | a=mid:2 | |||
SDP Answer - from splicer | SDP Answer - from the splicer: | |||
v=0 | v=0 | |||
o=xia 1122334455 1122334466 IN IP4 splicer.example.com | o=xia 1122334455 1122334466 IN IP4 splicer.example.com | |||
s=RTP Splicing Example | s=RTP Splicing Example | |||
t=0 0 | t=0 0 | |||
a=group:SPLICE 1 2 | a=group:SPLICE 1 2 | |||
m=video 30000 RTP/AVP 100 | m=video 30000 RTP/AVP 100 | |||
i=Main RTP Stream | i=Main RTP Stream | |||
c=IN IP4 splicer.example.com | c=IN IP4 splicer.example.com | |||
a=rtpmap:100 MP2T/90000 | a=rtpmap:100 MP2T/90000 | |||
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=recvonly | a=recvonly | |||
a=mid:1 | a=mid:1 | |||
m=video 40000 RTP/AVP 100 | m=video 40000 RTP/AVP 100 | |||
i=Substitutive RTP Stream | i=Substitutive RTP Stream | |||
c=IN IP4 splicer.example.com | c=IN IP4 splicer.example.com | |||
a=rtpmap:100 MP2T/90000 | a=rtpmap:100 MP2T/90000 | |||
a=recvonly | a=recvonly | |||
a=mid:2 | a=mid:2 | |||
6.3 Offer/Answer with BUNDLE: All Media are spliced | 6.3. Offer/Answer with BUNDLE: All Media Are Spliced | |||
In this example, the bundled audio and video media have their own | In this example, the bundled audio and video media have their own | |||
substitutive media for splicing: | substitutive media for splicing: | |||
1. An Offer, in which the offerer assigns a unique address and a | 1. An offer, in which the offerer assigns a unique address and a | |||
substitutive media to each bundled "m="line for splicing within the | substitutive media to each bundled "m=" line for splicing within | |||
BUNDLE group. | the BUNDLE group. | |||
2. An answer, in which the answerer selects its own BUNDLE address, | 2. An answer, in which the answerer selects its own BUNDLE address | |||
and leave the substitutive media untouched. | and leaves the substitutive media untouched. | |||
SDP Offer - from main RTP sender | SDP Offer - from the main RTP sender: | |||
v=0 | v=0 | |||
o=alice 1122334455 1122334466 IN IP4 splicing.example.com | o=alice 1122334455 1122334466 IN IP4 splicing.example.com | |||
s=RTP Splicing Example | s=RTP Splicing Example | |||
c=IN IP4 splicing.example.com | c=IN IP4 splicing.example.com | |||
t=0 0 | t=0 0 | |||
a=group:SPLICE foo 1 | a=group:SPLICE foo 1 | |||
a=group:SPLICE bar 2 | a=group:SPLICE bar 2 | |||
a=group:BUNDLE foo bar | a=group:BUNDLE foo bar | |||
m=audio 10000 RTP/AVP 0 8 97 | m=audio 10000 RTP/AVP 0 8 97 | |||
a=mid:foo | a=mid:foo | |||
b=AS:200 | b=AS:200 | |||
a=rtpmap:0 PCMU/8000 | a=rtpmap:0 PCMU/8000 | |||
a=rtpmap:8 PCMA/8000 | a=rtpmap:8 PCMA/8000 | |||
a=rtpmap:97 iLBC/8000 | a=rtpmap:97 iLBC/8000 | |||
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=sendonly | a=sendonly | |||
m=video 10002 RTP/AVP 31 32 | m=video 10002 RTP/AVP 31 32 | |||
a=mid:bar | a=mid:bar | |||
b=AS:1000 | b=AS:1000 | |||
a=rtpmap:31 H261/90000 | a=rtpmap:31 H261/90000 | |||
a=rtpmap:32 MPV/90000 | a=rtpmap:32 MPV/90000 | |||
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=sendonly | a=sendonly | |||
m=audio 20000 RTP/AVP 0 8 97 | m=audio 20000 RTP/AVP 0 8 97 | |||
i=Substitutive audio RTP Stream | i=Substitutive audio RTP Stream | |||
c=IN IP4 substitive.example.com | c=IN IP4 substitutive.example.com | |||
a=rtpmap:0 PCMU/8000 | a=rtpmap:0 PCMU/8000 | |||
a=rtpmap:8 PCMA/8000 | a=rtpmap:8 PCMA/8000 | |||
a=rtpmap:97 iLBC/8000 | a=rtpmap:97 iLBC/8000 | |||
a=sendonly | a=sendonly | |||
a=mid:1 | a=mid:1 | |||
m=video 20002 RTP/AVP 31 32 | m=video 20002 RTP/AVP 31 32 | |||
i=Substitutive video RTP Stream | i=Substitutive video RTP Stream | |||
c=IN IP4 substitive.example.com | c=IN IP4 substitutive.example.com | |||
a=rtpmap:31 H261/90000 | a=rtpmap:31 H261/90000 | |||
a=rtpmap:32 MPV/90000 | a=rtpmap:32 MPV/90000 | |||
a=mid:2 | a=mid:2 | |||
a=sendonly | a=sendonly | |||
SDP Answer - from the splicer | SDP Answer - from the splicer: | |||
v=0 | v=0 | |||
o=bob 2808844564 2808844564 IN IP4 splicer.example.com | o=bob 2808844564 2808844564 IN IP4 splicer.example.com | |||
s=RTP Splicing Example | s=RTP Splicing Example | |||
c=IN IP4 splicer.example.com | c=IN IP4 splicer.example.com | |||
t=0 0 | t=0 0 | |||
a=group:SPLICE foo 1 | a=group:SPLICE foo 1 | |||
a=group:SPLICE bar 2 | a=group:SPLICE bar 2 | |||
a=group:BUNDLE foo bar | a=group:BUNDLE foo bar | |||
m=audio 30000 RTP/AVP 0 | m=audio 30000 RTP/AVP 0 | |||
a=mid:foo | a=mid:foo | |||
b=AS:200 | b=AS:200 | |||
a=rtpmap:0 PCMU/8000 | a=rtpmap:0 PCMU/8000 | |||
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=recvonly | a=recvonly | |||
m=video 30000 RTP/AVP 32 | m=video 30000 RTP/AVP 32 | |||
a=mid:bar | a=mid:bar | |||
b=AS:1000 | b=AS:1000 | |||
a=rtpmap:32 MPV/90000 | a=rtpmap:32 MPV/90000 | |||
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=recvonly | a=recvonly | |||
m=audio 30002 RTP/AVP 0 | m=audio 30002 RTP/AVP 0 | |||
i=Substitutive audio RTP Stream | i=Substitutive audio RTP Stream | |||
c=IN IP4 splicer.example.com | c=IN IP4 splicer.example.com | |||
a=rtpmap:0 PCMU/8000 | a=rtpmap:0 PCMU/8000 | |||
a=recvonly | a=recvonly | |||
a=mid:1 | a=mid:1 | |||
m=video 30004 RTP/AVP 32 | m=video 30004 RTP/AVP 32 | |||
i=Substitutive video RTP Stream | i=Substitutive video RTP Stream | |||
c=IN IP4 splicer.example.com | c=IN IP4 splicer.example.com | |||
a=rtpmap:32 MPV/90000 | a=rtpmap:32 MPV/90000 | |||
a=mid:2 | a=mid:2 | |||
a=recvonly | a=recvonly | |||
6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced | 6.4. Offer/Answer with BUNDLE: A Subset of Media Are Spliced | |||
In this example, the substitutive media only applies for video when | In this example, the substitutive media only applies for video when | |||
splicing: | splicing: | |||
1. An Offer, in which the offerer assigns a unique address to each | 1. An offer, in which the offerer assigns a unique address to each | |||
bundled "m="line within the BUNDLE group, and assigns a substitutive | bundled "m=" line within the BUNDLE group and assigns a | |||
media to the bundled video "m=" line for splicing. | substitutive media to the bundled video "m=" line for splicing. | |||
2. An answer, in which the answerer selects its own BUNDLE address, | 2. An answer, in which the answerer selects its own BUNDLE address | |||
and leave the substitutive media untouched. | and leaves the substitutive media untouched. | |||
SDP Offer - from the main RTP sender: | SDP Offer - from the main RTP sender: | |||
v=0 | v=0 | |||
o=alice 1122334455 1122334466 IN IP4 splicing.example.com | o=alice 1122334455 1122334466 IN IP4 splicing.example.com | |||
s=RTP Splicing Example | s=RTP Splicing Example | |||
c=IN IP4 splicing.example.com | c=IN IP4 splicing.example.com | |||
t=0 0 | t=0 0 | |||
a=group:SPLICE bar 2 | a=group:SPLICE bar 2 | |||
a=group:BUNDLE foo bar | a=group:BUNDLE foo bar | |||
m=audio 10000 RTP/AVP 0 8 97 | m=audio 10000 RTP/AVP 0 8 97 | |||
a=mid:foo | a=mid:foo | |||
b=AS:200 | b=AS:200 | |||
a=rtpmap:0 PCMU/8000 | a=rtpmap:0 PCMU/8000 | |||
a=rtpmap:8 PCMA/8000 | a=rtpmap:8 PCMA/8000 | |||
a=rtpmap:97 iLBC/8000 | a=rtpmap:97 iLBC/8000 | |||
a=sendonly | a=sendonly | |||
m=video 10002 RTP/AVP 31 32 | m=video 10002 RTP/AVP 31 32 | |||
a=mid:bar | a=mid:bar | |||
b=AS:1000 | b=AS:1000 | |||
a=rtpmap:31 H261/90000 | a=rtpmap:31 H261/90000 | |||
a=rtpmap:32 MPV/90000 | a=rtpmap:32 MPV/90000 | |||
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=sendonly | a=sendonly | |||
m=video 20000 RTP/AVP 31 32 | m=video 20000 RTP/AVP 31 32 | |||
i=Substitutive video RTP Stream | i=Substitutive video RTP Stream | |||
c=IN IP4 substitutive.example.com | c=IN IP4 substitutive.example.com | |||
a=rtpmap:31 H261/90000 | a=rtpmap:31 H261/90000 | |||
a=rtpmap:32 MPV/90000 | a=rtpmap:32 MPV/90000 | |||
a=mid:2 | a=mid:2 | |||
a=sendonly | a=sendonly | |||
SDP Answer - from the splicer: | SDP Answer - from the splicer: | |||
v=0 | v=0 | |||
o=bob 2808844564 2808844564 IN IP4 splicer.example.com | o=bob 2808844564 2808844564 IN IP4 splicer.example.com | |||
s=RTP Splicing Example | s=RTP Splicing Example | |||
c=IN IP4 splicer.example.com | c=IN IP4 splicer.example.com | |||
t=0 0 | t=0 0 | |||
a=group:SPLICE bar 2 | a=group:SPLICE bar 2 | |||
a=group:BUNDLE foo bar | a=group:BUNDLE foo bar | |||
m=audio 30000 RTP/AVP 0 | m=audio 30000 RTP/AVP 0 | |||
a=mid:foo | a=mid:foo | |||
b=AS:200 | b=AS:200 | |||
a=rtpmap:0 PCMU/8000 | a=rtpmap:0 PCMU/8000 | |||
a=recvonly | a=recvonly | |||
m=video 30000 RTP/AVP 32 | m=video 30000 RTP/AVP 32 | |||
a=mid:bar | a=mid:bar | |||
b=AS:1000 | b=AS:1000 | |||
a=rtpmap:32 MPV/90000 | a=rtpmap:32 MPV/90000 | |||
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval | a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval | |||
a=recvonly | a=recvonly | |||
m=video 30004 RTP/AVP 32 | m=video 30004 RTP/AVP 32 | |||
i=Substitutive video RTP Stream | i=Substitutive video RTP Stream | |||
c=IN IP4 splicer.example.com | c=IN IP4 splicer.example.com | |||
a=rtpmap:32 MPV/90000 | a=rtpmap:32 MPV/90000 | |||
a=mid:2 | a=mid:2 | |||
a=recvonly | a=recvonly | |||
7 Security Considerations | 7. Security Considerations | |||
The security considerations of the RTP specification [RFC3550] and | The security considerations of the RTP specification [RFC3550] and | |||
the general mechanism for RTP header extensions [RFC5285bis] apply. | the general mechanism for RTP header extensions [RFC8285] apply. The | |||
The splicer can either be a mixer or a translator, and all the | splicer can be either a mixer or a translator, and all the security | |||
security considerations of these two RTP intermediaries topologies | considerations of topologies [RFC7667] [RFC7201] for these two types | |||
described in [RFC7667] and [RFC7201] are applicable for the splicer. | of RTP intermediaries are applicable for the splicer. | |||
The splicer replaces some content with other content in RTP packet, | The splicer replaces some content with other content in RTP packets, | |||
thus breaking any RTP-level end-to-end security, such as source | thus breaking any RTP-level end-to-end security, such as source | |||
authentication and integrity protection. End to end source | authentication and integrity protection. End-to-end source | |||
authentication is not possible with any known existing splicing | authentication is not possible with any known existing splicing | |||
solution. A new solution can theoretically be developed that enables | solution. A new solution can theoretically be developed that enables | |||
identification of the participating entities and what each provides, | identification of the participating entities and what each provides, | |||
i.e., the different media sources, main and substituting, and the | i.e., the different media sources -- main and substitutive -- and the | |||
splicer which provides the RTP-level integration of the media | splicer, which provides the RTP-level integration of the media | |||
payloads in a common timeline and synchronization context. | payloads in a common timeline and synchronization context. | |||
Since the splicer breaks RTP-level end-to-end security, it needs to | Since the splicer breaks RTP-level end-to-end security, it needs to | |||
be part of the signaling context and the necessary security | be part of the signaling context and the necessary security | |||
associations (e.g., SRTP crypto contexts) established for the RTP | associations (e.g., Secure Real-time Transport Protocol (SRTP) | |||
session participants. When using the Secure Real-Time Transport | ||||
Protocol (SRTP) [RFC3711], the splicer would have to be provisioned | ||||
with the same security association as the main RTP sender. | ||||
If there is a concern about the confidentiality of the splicing time | [RFC3711] crypto contexts) established for the RTP session | |||
information, the header extension defined in this document MUST be | participants. When using SRTP, the splicer would have to be | |||
also protected, for example, header extension encryption [RFC6904] | provisioned with the same security association as the main RTP | |||
can be used in this case. However, the malicious endpoint may get the | sender. | |||
splicing time information by other means, e.g., inferring from the | ||||
communication between the main and substitutive content sources. To | If there are concerns about the confidentiality of the splicing time | |||
information, the header extension defined in this document MUST also | ||||
be protected; for example, header extension encryption [RFC6904] can | ||||
be used in this case. However, the malicious endpoint may get the | ||||
splicing time information by other means, e.g., inferring it from the | ||||
communication between the main and substitutive content sources. To | ||||
avoid the insertion of invalid substitutive content, the splicer MUST | avoid the insertion of invalid substitutive content, the splicer MUST | |||
have some mechanisms to authenticate the substitutive stream source. | have some mechanisms to authenticate the substitutive stream source. | |||
For cases that the splicing time information is changed by a | For cases where the splicing time information is changed by a | |||
malicious endpoint, the splicing, for example, may fail since it will | malicious endpoint, the splicing, for example, may fail, since it | |||
not be available at the right time for the substitutive media to | will not be available at the right time for the substitutive media to | |||
arrive. Another case is that an attacker may prevent the receivers | arrive. Another case is one where an attacker may prevent the | |||
receiving the content from the main sender by inserting extra | receivers from receiving the content from the main sender by | |||
splicing time information. To avoid the above cases happening, the | inserting extra splicing time information. To avoid the above | |||
authentication of the RTP header extension for splicing time | scenarios, the authentication of the RTP header extension for | |||
information SHOULD be considered. | splicing time information SHOULD be considered. | |||
When a splicer implemented as a mixer sends the stream to the | When a splicer implemented as a mixer sends the stream to the | |||
receivers, CSRC list, which can be used to detect RTP-level | receivers, the CSRC list, which can be used to detect RTP-level | |||
forwarding loops as defined in Section 8.2 of [RFC3550], may be | forwarding loops as defined in Section 8.2 of [RFC3550], may be | |||
removed for simplifying the receivers that can not handle multiple | removed for simplifying the receivers that cannot handle multiple | |||
sources in the RTP stream. Hence, loops may occur to cause packets to | sources in the RTP stream. Hence, loops may occur, causing packets | |||
loop back to upstream of the splicer and may form a serious denial- | to loop back to a point upstream of the splicer and possibly forming | |||
of-service threat. In such a case, non-RTP means, e.g., signaling | a serious denial-of-service threat. In such a case, non-RTP means, | |||
among all the participants, MUST be used to detect and resolve loops. | e.g., signaling among all the participants, MUST be used to detect | |||
and resolve loops. | ||||
8 IANA Considerations | ||||
8.1 RTCP Control Packet Types | 8. IANA Considerations | |||
Based on the guidelines suggested in [RFC5226], a new RTCP packet | 8.1. RTCP Control Packet Types | |||
format has been registered with the RTCP Control Packet Type (PT) | ||||
Registry: | ||||
Name: SNM | Based on the guidelines suggested in [RFC8126], a new RTCP packet | |||
format has been registered in the "RTCP Control Packet types (PT)" | ||||
registry: | ||||
Long name: Splicing Notification Message | Name: SNM | |||
Value: TBA | Long name: Splicing Notification Message | |||
Reference: This document | Value: 213 | |||
8.2 RTP Compact Header Extensions | Reference: This document | |||
The IANA has also registered a new RTP Compact Header Extension | 8.2. RTP Compact Header Extensions | |||
[RFC5285bis], according to the following: | ||||
Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval | IANA has registered a new RTP Compact Header Extension [RFC8285], | |||
according to the following: | ||||
Description: Splicing Interval | Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval | |||
Contact: Jinwei Xia <xiajinwei@huawei.com> | Description: Splicing Interval | |||
Reference: This document | Contact: Jinwei Xia <xiajinwei@huawei.com> | |||
8.3 SDP Grouping Semantic Extension | Reference: This document | |||
This document request IANA to register the new SDP grouping semantic | ||||
extension called "SPLICE". | ||||
Semantics: Splice | 8.3. SDP Grouping Semantic Extension | |||
Token:SPLICE | IANA has registered the new SDP grouping semantic extension called | |||
"SPLICE" in the "Semantics for the 'group' SDP Attribute" subregistry | ||||
of the "Session Description Protocol (SDP) Parameters" registry: | ||||
Reference: This document | Semantics: Splice | |||
9 Acknowledgement | Token: SPLICE | |||
The authors would like to thank the following individuals who help to | Reference: This document | |||
review this document and provide very valuable comments: Colin | ||||
Perkins, Bo Burman, Stephen Botzko, Ben Campbell. | ||||
10 References | 9. References | |||
10.1 Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | ||||
with Session Description Protocol (SDP)", RFC 3264, | ||||
DOI 10.17487/RFC3264, June 2002, | ||||
<https://www.rfc-editor.org/info/rfc3264>. | ||||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <https://www.rfc-editor.org/info/rfc3550>. | ||||
[RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model | ||||
with the Session Description Protocol (SDP)", RFC 3264, | ||||
June 2002. | ||||
[RFC5285bis] Even, R., Singer, D. and H. Desineni, "A General | ||||
Mechanism for RTP Header Extensions", draft-ietf-avtcore- | ||||
rfc5285-bis-02, May 2016. | ||||
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description | |||
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. | Protocol (SDP) Grouping Framework", RFC 5888, | |||
DOI 10.17487/RFC5888, June 2010, | ||||
<https://www.rfc-editor.org/info/rfc5888>. | ||||
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | |||
"Network Time Protocol Version 4: Protocol and Algorithms | "Network Time Protocol Version 4: Protocol and Algorithms | |||
Specification", RFC 5905, June 2010. | Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, | |||
<https://www.rfc-editor.org/info/rfc5905>. | ||||
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP | [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP | |||
Flows", RFC 6051, November 2010. | Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, | |||
<https://www.rfc-editor.org/info/rfc6051>. | ||||
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | |||
Sessions", RFC 7201, April 2014. | Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, | |||
<https://www.rfc-editor.org/info/rfc7201>. | ||||
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, | [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, | |||
November 2015. | DOI 10.17487/RFC7667, November 2015, | |||
<https://www.rfc-editor.org/info/rfc7667>. | ||||
10.2 Informative References | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in | |||
RFC 2119 Key Words", BCP 14, RFC 8174, | ||||
DOI 10.17487/RFC8174, May 2017, | ||||
<https://www.rfc-editor.org/info/rfc8174>. | ||||
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General | ||||
Mechanism for RTP Header Extensions", RFC 8285, | ||||
DOI 10.17487/RFC8285, October 2017, | ||||
<https://www.rfc-editor.org/info/rfc8285>. | ||||
9.2. Informative References | ||||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, March 2004. | RFC 3711, DOI 10.17487/RFC3711, March 2004, | |||
<https://www.rfc-editor.org/info/rfc3711>. | ||||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
May 2008. | ||||
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size | [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size | |||
Real-Time Transport Control Protocol (RTCP): Opportunities | Real-Time Transport Control Protocol (RTCP): Opportunities | |||
and Consequences", RFC 5506, April 2009. | and Consequences", RFC 5506, DOI 10.17487/RFC5506, | |||
April 2009, <https://www.rfc-editor.org/info/rfc5506>. | ||||
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, | [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, | |||
"Unicast-Based Rapid Acquisition of Multicast RTP | "Unicast-Based Rapid Acquisition of Multicast RTP | |||
Sessions", RFC 6285, June 2011. | Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011, | |||
<https://www.rfc-editor.org/info/rfc6285>. | ||||
[RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure | [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, | |||
Real-Time Transport Protocol (SRTP)", April 2013. | DOI 10.17487/RFC6828, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6828>. | ||||
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure | ||||
Real-time Transport Protocol (SRTP)", RFC 6904, | ||||
DOI 10.17487/RFC6904, April 2013, | ||||
<https://www.rfc-editor.org/info/rfc6904>. | ||||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | ||||
Writing an IANA Considerations Section in RFCs", BCP 26, | ||||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | ||||
<https://www.rfc-editor.org/info/rfc8126>. | ||||
[SCTE35] Society of Cable Telecommunications Engineers (SCTE), | [SCTE35] Society of Cable Telecommunications Engineers (SCTE), | |||
"Digital Program Insertion Cueing Message for Cable", | "Digital Program Insertion Cueing Message for Cable", | |||
2011. | 2016, <http://www.scte.org/SCTEDocs/Standards/ | |||
SCTE%2035%202016.pdf>. | ||||
[RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, | Acknowledgements | |||
January 2013. | ||||
The authors would like to thank the following individuals who helped | ||||
to review this document and provided very valuable comments: Colin | ||||
Perkins, Bo Burman, Stephen Botzko, and Ben Campbell. | ||||
Authors' Addresses | Authors' Addresses | |||
Jinwei Xia | Jinwei Xia | |||
Huawei | Huawei | |||
Email: xiajinwei@huawei.com | Email: xiajinwei@huawei.com | |||
Roni Even | Roni Even | |||
Huawei | Huawei | |||
Email: ron.even.tlv@gmail.com | Email: roni.even@huawei.com | |||
Rachel Huang | Rachel Huang | |||
Huawei | Huawei | |||
Email: rachel.huang@huawei.com | Email: rachel.huang@huawei.com | |||
Lingli Deng | Lingli Deng | |||
China Mobile | China Mobile | |||
Email: denglingli@chinamobile.com | Email: denglingli@chinamobile.com | |||
End of changes. 162 change blocks. | ||||
611 lines changed or deleted | 637 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |