draft-ietf-avtext-splicing-notification-07.txt | draft-ietf-avtext-splicing-notification-08.txt | |||
---|---|---|---|---|
AVTEXT Working Group J. Xia | AVTEXT Working Group J. Xia | |||
INTERNET-DRAFT R. Even | INTERNET-DRAFT R. Even | |||
Intended Status: Standards Track R. Huang | Intended Status: Standards Track R. Huang | |||
Expires: November 18, 2016 Huawei | Expires: December 30, 2016 Huawei | |||
L. Deng | L. Deng | |||
China Mobile | China Mobile | |||
May 17, 2016 | June 28, 2016 | |||
RTP/RTCP extension for RTP Splicing Notification | RTP/RTCP extension for RTP Splicing Notification | |||
draft-ietf-avtext-splicing-notification-07 | draft-ietf-avtext-splicing-notification-08 | |||
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 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 | |||
skipping to change at page 2, line 24 ¶ | skipping to change at page 2, line 24 ¶ | |||
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 of RTP Splicing Notification . . . . . . . . . . . . . 4 | 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1 Overview of RTP Splicing . . . . . . . . . . . . . . . . . . 4 | ||||
2.2 Overview of Splicing Interval . . . . . . . . . . . . . . . 5 | ||||
3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 | 3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 | |||
3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5 | 3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 | 3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 | |||
4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 | 4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 | |||
5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9 | 6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9 | 6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9 | |||
6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10 | 6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10 | |||
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 . . 12 | |||
skipping to change at page 3, line 20 ¶ | skipping to change at page 3, line 20 ¶ | |||
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 layer in cable TV systems. When transported in | |||
RTP, an middle box designed as the splicer to decode the RTP packets | RTP, an middle box designed as the splicer to decode the RTP packets | |||
and search for the Splicing Interval inside the payloads is required. | and search for the Splicing Interval inside the payloads is required. | |||
The middle box is either a translator or a mixer as described in | The need for such processing increases the workload of the middle box | |||
[RFC6828]. The need for such processing increases the workload of the | and limits the number of RTP sessions the middle box can support. | |||
middle box and limits the number of RTP sessions the middle box can | ||||
support. | ||||
The document defines an RTP header extension [RFC5285] used by the | The document defines an RTP header extension [RFC5285] 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 un-aware | |||
middlebox on the path between the RTP sender might strip this RTP | middlebox on the path between the RTP sender might strip this RTP | |||
header extension. | header extension. | |||
To increase robustness against such case, the document also defines a | To increase robustness against such case, the document also defines a | |||
complementary RTCP packet type to carry the same Splicing Interval to | new RTCP packet type to carry the same Splicing Interval to the | |||
the splicer. | splicer. Since RTCP is also unreliable and may not be so immediate as | |||
the in-band way, it's only considered as 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", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
In addition, we define following terminologies: | In addition, we define following terminologies: | |||
Main RTP sender: | Main RTP sender: | |||
skipping to change at page 4, line 33 ¶ | skipping to change at page 4, line 33 ¶ | |||
The NTP-format timestamps, representing the main RTP sender | The NTP-format timestamps, representing the main RTP sender | |||
wallclock time, for the Splicing-In point and Splicing-Out point | wallclock time, for the Splicing-In point and Splicing-Out point | |||
per [RFC6828] allowing the splicer to know when to start and end | per [RFC6828] allowing the splicer to know when to start and end | |||
the RTP splicing. | the 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 of RTP Splicing Notification | 2 Overview | |||
A splicer is designed to handle splicing on the RTP layer at the | 2.1 Overview of RTP Splicing | |||
reserved time slots set by the main RTP sender. This implies that the | ||||
splicer must first know the Splicing Interval from the main RTP | RTP Splicing is intended to replace some multimedia content with | |||
sender before it can start splicing. The splicer can be a mixer as | certain substitutive multimedia content, and then forward it to the | |||
described in [RFC6828]. | receivers for a period of time. This process is authorized by the | |||
main RTP sender that offers a specific time window for inserting the | ||||
substitutive multimedia content in the main content. A typical usage | ||||
is that IPTV service provider uses its own regional advertising | ||||
content to replace national advertising content, the time window of | ||||
which is explicitly indicated by the IPTV service provider. | ||||
The splicer is a middlebox handling RTP splicing. It receives main | ||||
content and substitutive content simultaneously but only chooses to | ||||
send one of them to the receiver at any point of time. When RTP | ||||
splicing begins, the splicer sends the substitutive content to the | ||||
receivers instead of the main content. When RTP splicing ends, the | ||||
splicer switches back to sending the main content to the receivers. | ||||
This implies that the receiver is explicitly configured to receive | ||||
the traffic via the splicer, and will return any RTCP feedback to it | ||||
in the presence of the splicer. | ||||
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, | ||||
[RFC6828] specifies how the splicer can use its own SSRC, sequence | ||||
number space, and timing model when generating the output stream to | ||||
receivers, using the CSRC list to indicate whether the original or | ||||
substitutive content is being delivered. The splicer, on behalf of | ||||
the content provider, can omit 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 place (it requires inspection of the RTP | ||||
payload data, rather than just the RTP headers). A splicer working as | ||||
an RTP mixer splits the flow between the sender and receiver into | ||||
two, and requires separate control loops, for RTCP and congestion | ||||
control, see Section 4.4 of [RFC6828]. | ||||
A splicer implemented as an RTP translator [RFC3550] will forward the | ||||
RTP packets from the original and substitutive senders with their | ||||
SSRCs intact, but will need to rewrite RTCP sender report packets to | ||||
account for the splicing. In this case, the congestion control loops | ||||
run between original sender and receiver, and between the | ||||
substitutive sender and receiver. The splicer needs to ensure that | ||||
the RTCP feedback message from the receiver are passed to the right | ||||
sender to let the congestion control work. | ||||
2.2 Overview of Splicing Interval | ||||
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 | ||||
Interval from the main RTP sender before it can start splicing. The | ||||
splicer can be a mixer as described in [RFC6828]. | ||||
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 be | |||
sent more than once to mitigate the possible packet loss. To enable | sent by RTP header extension or RTCP extension message more than once | |||
the splicer to get the substitutive content before the splicing | to mitigate the possible packet loss. To enable the splicer to get | |||
starts, the main RTP sender MUST send the Splicing Interval far | the substitutive content before the splicing starts, the main RTP | |||
ahead. For example, the main RTP sender can estimate when to send the | sender MUST send the Splicing Interval far ahead. For example, the | |||
Splicing Interval based on the round-trip time (RTT) following the | main RTP sender can estimate when to send the Splicing Interval based | |||
mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP | on the round-trip time (RTT) following the mechanisms in section | |||
RR to the main sender. | 6.4.1 of [RFC3550] when the splicer sends RTCP 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 thus estimates when to | |||
transfer the substitutive content to the splicer. The Splicing | transfer the substitutive content to the splicer. The Splicing | |||
Interval could be transmitted from the main RTP sender to the | Interval could be transmitted from the main RTP sender to the | |||
substitutive content using some out-of-band mechanisms, for example, | substitutive content using some out-of-band mechanisms, for example, | |||
a proprietary mechanism to exchange the Splicing Interval, or the | a proprietary mechanism to exchange the Splicing Interval, or the | |||
substitutive sender is implemented together with the main RTP sender | substitutive sender is implemented together with the main RTP sender | |||
inside a single device. To ensure the Splicing Interval is valid for | inside a single device. To ensure 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 | |||
skipping to change at page 7, line 27 ¶ | skipping to change at page 8, line 27 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
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 inserts the RTP header extensions into only a number of RTP | |||
packets, instead of all the RTP packets, prior to the splicing in. | packets, instead of all the RTP packets, prior to the splicing in. | |||
After the splicer intercepts the RTP header extension and derives the | After the splicer obtains the RTP header extension and derives the | |||
Splicing Interval, it will generate its own stream and SHOULD NOT | 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 to reduce header | |||
overhead. | 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 the RTP header extension, the main RTP sender includes | |||
the Splicing Interval in an RTCP splicing notification message. | the Splicing Interval in an RTCP splicing notification message. | |||
Whether or not the timestamps are included in the RTP header | Whether or not the timestamps are included in the RTP header | |||
extension, the main RTP sender MUST send the RTCP splicing | extension, the main RTP sender MUST send the RTCP splicing | |||
notification message. This provide robustness in the case where a | notification message. This provide robustness in the case where a | |||
skipping to change at page 9, line 5 ¶ | skipping to change at page 10, line 5 ¶ | |||
6.1 in [RFC3550]. | 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 | message may be sent as non-compound RTCP packets. In some cases that | |||
the mapping from RTP timestamp to NTP timestamp changes, e.g., clock | the mapping from RTP timestamp to NTP timestamp changes, e.g., clock | |||
drift happening before the splicing event, it may be required to send | drift happening before the splicing event, it may be required to send | |||
RTCP SR or even updated Splicing Interval information timely to | RTCP SR or even updated Splicing Interval information timely to | |||
update the timestamp mapping for accurate splicing. | update the timestamp mapping for accurate splicing. | |||
When the splicer intercepts the RTCP splicing notification message, | Since the RTCP splicing notification message is intentionally sent by | |||
it SHOULD NOT forward the message to the down-stream receivers in | the main RTP sender to the splicer, the splicer is not allowed to | |||
order to reduce RTCP bandwidth consumption. And if the splicer wishes | forward this message to the receivers so as to avoid their useless | |||
to prevent the downstream receivers from detecting splicing, it MUST | processing and additional RTCP bandwidth consumption in the | |||
NOT forward the message. | downstream. | |||
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 Information | |||
is distributed to the receivers is out of scope of this memo. | is distributed to the receivers is out of scope of this memo. | |||
Another latency element is synchronization caused delay. The | Another latency element is synchronization caused delay. 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 and the substitutive sender | synchronized fashion. The main RTP sender or the substitutive sender | |||
can be coordinated by some proprietary out-of-band mechanisms to | can estimate when to send the synchronization metadata based on, for | |||
decide when and whom to send the metadata. If both send the | example, the round-trip time (RTT) following the mechanisms in | |||
information, the splicer SHOULD pick one based on the current | section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main | |||
situation, e.g., choosing media sender when synchronizing the main | sender or the substitutive sender. The main RTP sender and the | |||
media content while choosing the information from the substitutive | substitutive sender can also be coordinated by some proprietary out- | |||
sender when synchronizing the spliced content. The mechanisms defined | of-band mechanisms to decide when and whom to send the metadata. If | |||
in [RFC6051] are RECOMMENDED to be adopted to reduce the possible | both send the information, the splicer SHOULD pick one based on the | |||
synchronization delay. | current situation, e.g., choosing main RTP sender when synchronizing | |||
the main media content while choosing the information from the | ||||
substitutive sender when synchronizing the spliced content. The | ||||
mechanisms defined in [RFC6051] are RECOMMENDED to be adopted to | ||||
reduce the possible synchronization delay. | ||||
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 message and the other failure case, e.g., the RTP header | |||
extension is stripped on the path. | extension is stripped on the path. | |||
Given that there may be a splicing un-aware middlebox on the path | Given that there may be a splicing un-aware 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 the | |||
substitutive RTP senders can use one heuristic to verify whether or | substitutive RTP senders can use one heuristic to verify whether or | |||
skipping to change at page 16, line 37 ¶ | skipping to change at page 17, line 37 ¶ | |||
The splicer replaces some content with other content in RTP packet, | The splicer replaces some content with other content in RTP packet, | |||
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 substituting, 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 splicer works as a trusted entity, any RTP-level or outside | Since the splicer breaks RTP-level end-to-end security, it needs to | |||
security mechanism, such as IPsec[RFC4301] or Datagram Transport | be part of the signaling context and the necessary security | |||
Layer Security [RFC6347], will use a security association between the | associations (e.g., SRTP crypto contexts) established for the RTP | |||
splicer and the receiver. When using the Secure Real-Time Transport | session participants. When using the Secure Real-Time Transport | |||
Protocol (SRTP) [RFC3711], the splicer could be provisioned with the | Protocol (SRTP) [RFC3711], the splicer would have to be provisioned | |||
same security association as the main RTP sender. | with the same security association as the main RTP sender. | |||
If there is a concern about the confidentiality of the splicing time | If there is a concern about the confidentiality of the splicing time | |||
information, header extension encryption [RFC6904] SHOULD be used. | information, the header extension defined in this document MUST be | |||
However, the malicious endpoint may get the splicing time information | also protected, for example, header extension encryption [RFC6904] | |||
by other means, e.g., inferring from the communication between the | can be used in this case. However, the malicious endpoint may get the | |||
main and substitutive content sources. To avoid the insertion of | splicing time information by other means, e.g., inferring from the | |||
invalid substitutive content, the splicer MUST have some mechanisms | communication between the main and substitutive content sources. To | |||
to authenticate the substitutive stream source. | avoid the insertion of invalid substitutive content, the splicer MUST | |||
have some mechanisms to authenticate the substitutive stream source. | ||||
For cases that the splicing time information is changed by a | For cases that 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 will | |||
not be available at the right time for the substitutive media to | 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 that an attacker may prevent the receivers | |||
receiving the content from the main sender by inserting extra | receiving the content from the main sender by inserting extra | |||
splicing time information. To avoid the above cases happening, the | splicing time information. To avoid the above cases happening, the | |||
authentication of the RTP header extension for splicing time | authentication of the RTP header extension for splicing time | |||
information SHOULD be considered. | information SHOULD be considered. | |||
A malicious endpoint may also break an undetectable splicing. To | When a splicer implemented as a mixer sends the stream to the | |||
mitigate this effect, the splicer SHOULD NOT forward the splicing | receivers, CSRC list, which can be used to detect RTP-level | |||
time information RTP header extension defined in Section 4.1 to the | forwarding loops as defined in Section 8.2 of [RFC3550], may be | |||
receivers. And it MUST NOT forward this header extension when | removed for simplifying the receivers that can not handle multiple | |||
considering an undetectable splicing. | sources in the RTP stream. Hence, loops may occur to cause packets to | |||
loop back to upstream of the splicer and may form a serious denial- | ||||
of-service threat. In such a case, non-RTP means, e.g., signaling | ||||
among all the participants, MUST be used to detect and resolve loops. | ||||
8 IANA Considerations | 8 IANA Considerations | |||
8.1 RTCP Control Packet Types | 8.1 RTCP Control Packet Types | |||
Based on the guidelines suggested in [RFC5226], a new RTCP packet | Based on the guidelines suggested in [RFC5226], a new RTCP packet | |||
format has been registered with the RTCP Control Packet Type (PT) | format has been registered with the RTCP Control Packet Type (PT) | |||
Registry: | Registry: | |||
Name: SNM | Name: SNM | |||
skipping to change at page 17, line 50 ¶ | skipping to change at page 19, line 4 ¶ | |||
Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval | Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval | |||
Description: Splicing Interval | Description: Splicing Interval | |||
Contact: Jinwei Xia <xiajinwei@huawei.com> | Contact: Jinwei Xia <xiajinwei@huawei.com> | |||
Reference: This document | Reference: This document | |||
8.3 SDP Grouping Semantic Extension | 8.3 SDP Grouping Semantic Extension | |||
This document request IANA to register the new SDP grouping semantic | This document request IANA to register the new SDP grouping semantic | |||
extension called "SPLICE". | extension called "SPLICE". | |||
Semantics: Splice | Semantics: Splice | |||
Token:SPLICE | Token:SPLICE | |||
Reference: This document | Reference: This document | |||
Contact: Jinwei Xia <xiajinwei@huawei.com> | ||||
9 Acknowledgement | 9 Acknowledgement | |||
The authors would like to thank the following individuals who help to | The authors would like to thank the following individuals who help to | |||
review this document and provide very valuable comments: Colin | review this document and provide very valuable comments: Colin | |||
Perkins, Bo Burman, Stephen Botzko, Ben Campbell. | Perkins, Bo Burman, Stephen Botzko, Ben Campbell. | |||
10 References | 10 References | |||
10.1 Normative References | 10.1 Normative References | |||
skipping to change at page 18, line 34 ¶ | skipping to change at page 19, line 34 ¶ | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[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, July 2003. | |||
[RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model | [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model | |||
with the Session Description Protocol (SDP)", RFC 3264, | with the Session Description Protocol (SDP)", RFC 3264, | |||
June 2002. | June 2002. | |||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | ||||
Internet Protocol", RFC 4301, December 2005. | ||||
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP | [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP | |||
Header Extensions", RFC 5285, July 2008. | Header Extensions", RFC 5285, July 2008. | |||
[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, June 2010. | |||
[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, June 2010. | |||
[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, November 2010. | |||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | ||||
Security Version 1.2", RFC 6347, January 2012. | ||||
[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, April 2014. | |||
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, | [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, | |||
November 2015. | November 2015. | |||
10.2 Informative References | 10.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)", | |||
End of changes. 19 change blocks. | ||||
65 lines changed or deleted | 113 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |