draft-ietf-avtext-splicing-notification-04.txt | draft-ietf-avtext-splicing-notification-05.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: July 29, 2016 Huawei | Expires: September 22, 2016 Huawei | |||
L. Deng | L. Deng | |||
China Mobile | China Mobile | |||
January 26, 2016 | March 21, 2016 | |||
RTP/RTCP extension for RTP Splicing Notification | RTP/RTCP extension for RTP Splicing Notification | |||
draft-ietf-avtext-splicing-notification-04 | draft-ietf-avtext-splicing-notification-05 | |||
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 3, line 29 ¶ | skipping to change at page 3, line 29 ¶ | |||
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 middle box is either a translator or a mixer as described in | |||
[RFC6828]. The need for such processing increases the workload of the | [RFC6828]. The need for such processing increases the workload of the | |||
middle box and limits the number of RTP sessions the middle box can | middle box and limits the number of RTP sessions the middle box can | |||
support. | 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. | |||
Nevertheless, the Splicing Interval conveyed in the RTP header | However, the Splicing Interval conveyed in the RTP header extension | |||
extension might not reach the splicer successfully. Any splicing un- | might not reach the splicer successfully. Any splicing un-aware | |||
aware middlebox on the path between the RTP sender might strip this | middlebox on the path between the RTP sender might strip this RTP | |||
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 | complementary RTCP packet type to carry the same Splicing Interval to | |||
the splicer. | the splicer. | |||
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]. | |||
skipping to change at page 4, line 23 ¶ | skipping to change at page 4, line 23 ¶ | |||
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 timestamps for the Splicing-In point and Splicing-Out | The NTP-format timestamps, representing the main RTP sender | |||
point per [RFC6828] allowing the splicer to know when to start and | wallclock time, for the Splicing-In point and Splicing-Out point | |||
end the RTP splicing. | per [RFC6828] allowing the splicer to know when to start and end | |||
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 of RTP Splicing Notification | |||
A splicer is designed to handle splicing on the RTP layer at the | A splicer is designed to handle splicing on the RTP layer at the | |||
reserved time slots set by the main RTP sender. This implies that the | reserved time slots set by the main RTP sender. This implies that the | |||
skipping to change at page 5, line 27 ¶ | skipping to change at page 5, line 29 ¶ | |||
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-format | |||
timestamps, to indicate when to start and end the splicing to the | timestamps, to indicate when to start and end the splicing to the | |||
splicer: the timestamp of the first substitutive RTP packet at the | splicer: the timestamp of the first substitutive RTP packet at the | |||
splicing in point, and the timestamp of the first main RTP packet at | splicing in point, and the timestamp of the first main RTP packet at | |||
the splicing out point. | the 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 and the substitutive | |||
content providers MUST ensure that the RTP timestamp of the first | content providers MUST ensure that the RTP timestamp of the first | |||
substitutive RTP packet that would be presented to the receivers | substitutive RTP packet that would be presented to the receivers | |||
corresponds to the same time instant as the former NTP timestamp in | corresponds to the same time instant as the former NTP-format | |||
the Splicing Interval. To enable the splicer to know the first | timestamp in the Splicing Interval. To enable the splicer to know the | |||
substitutive RTP packet it needs to send, the substitutive RTP sender | first substitutive RTP packet it needs to send, the substitutive RTP | |||
MUST send the substitutive RTP packet ahead of the Splicing In point, | sender MUST send the substitutive RTP packet ahead of the Splicing In | |||
allowing the splicer to find out the timestamp of this first RTP | point, allowing the splicer to find out the timestamp of this first | |||
packet in the substitutive RTP stream, e.g., using a prior RTCP SR | RTP packet in the substitutive RTP stream, e.g., using a prior RTCP | |||
message. | SR (Sender Report) message. | |||
When the splicing will end, the main content provider and the | When the splicing will end, the main content provider and the | |||
substitutive content provider MUST ensure the RTP timestamp of the | substitutive content provider MUST ensure the RTP timestamp of the | |||
first main RTP packet that would be presented on the receivers | first main RTP packet that would be presented on the receivers | |||
corresponds to the same time instant as the latter NTP timestamp in | corresponds to the same time instant as the latter NTP-format | |||
the Splicing Interval. | 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 backwards 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 [RFC5285] can be | The RTP header extension mechanism defined in [RFC5285] can be | |||
adapted to carry the Splicing Interval consisting of a pair of NTP- | adapted to carry the Splicing Interval consisting of a pair of NTP- | |||
format timestamps. | format timestamps. Two variants are defined for this header | |||
extension: one-byte header variant and two-byte header variant. | ||||
One variant is defined for this header extension. It carries the 7 | For one-byte header variant, it carries the 7 octets splicing-out | |||
octets splicing-out NTP timestamp (lower 24-bit part of the Seconds | NTP-format timestamp (lower 24-bit part of the Seconds of a NTP- | |||
of a NTP-format timestamp and the 32 bits of the Fraction of a NTP- | format timestamp and the 32 bits of the Fraction of a NTP-format | |||
format timestamp as defined in [RFC5905]), followed by the 8 octets | timestamp as defined in [RFC5905]), followed by the 8 octets | |||
splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in | splicing-in NTP-format timestamp (64-bit NTP-format timestamp as | |||
[RFC5905]). The top 8 bits of the splicing-out NTP timestamp are | defined in [RFC5905]). The top 8 bits of the splicing-out NTP | |||
inferred from the top 8 bits of the splicing-in NTP timestamp. This | timestamp are inferred from the top 8 bits of the splicing-in NTP | |||
is unambiguous, under the assumption that the splicing-out time is | timestamp. This is unambiguous, under the assumption that the | |||
after the splicing-in time, and the splicing interval is less than | splicing-out time is after the splicing-in time, and the splicing | |||
2^25 seconds. If the 7 octets splicing-out NTP timestamp is smaller | interval is less than 2^25 seconds. Therefore, if the value of 7 | |||
than the lower 7 octets splicing-in NTP timestamp, it implies a wrap | octets splicing-out NTP-format timestamp is smaller than the value of | |||
of the 64-bit splicing-out NTP timestamp which will then be | 7 lower octets splicing-in NTP-format, it implies a wrap of the 56- | |||
calculated by the 7 octets splicing-out NTP timestamp plus | bit splicing-out NTP-format timestamp which means the top 8-bit value | |||
0x100000000. Otherwise, the top 8 octets of splicing-out NTP | of the 64-bit splicing-out is equal to the top 8-bit value of | |||
timestamp is equal to the top 8 octets of splicing-in NTP timestamp. | splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 bits of | |||
splicing-out NTP timestamp is equal to the top 8 bits of splicing-in | ||||
NTP Timestamp. | ||||
The format is shown in Figures 1. | The format is shown in Figures 1. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| 0xBE | 0xDE | length=4 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | |||
| ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x | | ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | |||
| OUT NTP timestamp format - Fraction (bit 0-31) |e | | OUT NTP timestamp format - Fraction (bit 0-31) |e | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | |||
| IN NTP timestamp format - Seconds (bit 0-31) |s | | IN NTP timestamp format - Seconds (bit 0-31) |s | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | |||
| IN NTP timestamp format - Fraction (bit 0-31) |o | | IN NTP timestamp format - Fraction (bit 0-31) |o | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | |||
Figure 1: Sample hybrid NTP Encoding Using | Figure 1: Splicing Interval | |||
the One-Byte Header Format | Using the One-Byte Header Format | |||
For two-byte header variant, it carries the 6 octets splicing-out | ||||
NTP-format timestamp (lower 16-bit part of the Seconds of a NTP- | ||||
format timestamp and the 32 bits of the Fraction of a NTP-format | ||||
timestamp as defined in [RFC5905]), followed by the 8 octets | ||||
splicing-in NTP-format timestamp (64-bit NTP-format timestamp as | ||||
defined in [RFC5905]). Also, the top 16 bits of the splicing-out NTP | ||||
timestamp are inferred from the top 16 bits of the splicing-in NTP | ||||
timestamp, under the assumption that the splicing-out time is after | ||||
the splicing-in time, and the splicing interval is less than 2^16 | ||||
seconds. Similar to the one-byte header, if the value of 6 octets | ||||
splicing-out NTP-format timestamp is smaller than the value of 6 | ||||
lower octets splicing-in NTP-format, it implies a wrap of the 48-bit | ||||
splicing-out NTP-format timestamp which means the top 16-bit value of | ||||
the 64-bit splicing-out is equal to the top 16-bit value of splicing- | ||||
in NTP Timestamp plus 0x01. Otherwise, the top 16 bits of splicing- | ||||
out NTP timestamp is equal to the top 16 bits of splicing-in NTP | ||||
Timestamp. | ||||
The format is shown in Figures 2. | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E | ||||
| ID | L=14 | OUT NTP timestamp - Seconds |x | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t | ||||
| OUT NTP timestamp format - Fraction (bit 0-31) |e | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | ||||
| IN NTP timestamp format - Seconds (bit 0-31) |s | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i | ||||
| IN NTP timestamp format - Fraction (bit 0-31) |o | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n | ||||
Figure 2: Splicing Interval | ||||
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 intercepts the RTP header extension and derives the | |||
Splicing Interval, it will generate its own stream and SHOULD NOT | Splicing Interval, it will generate its own stream and SHOULD NOT | |||
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 | |||
middlebox strips RTP header extensions. | middlebox strips RTP header extensions. The main RTP sender MUST make | |||
sure the splicing information contained in the RTCP splicing | ||||
notification message consistent with the information 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-format 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=TBA | length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SSRC | | | SSRC | | |||
skipping to change at page 7, line 49 ¶ | skipping to change at page 8, line 42 ¶ | |||
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 timestamp is used, which is a 64-bit, | The full-resolution NTP-format timestamp is used, which is a 64- | |||
unsigned, fixed-point number with the integer part in the first 32 | bit, unsigned, fixed-point number with the integer part in the | |||
bits and the fractional part in the last 32 bits. This format is | first 32 bits and the fractional part in the last 32 bits. This | |||
similar to the RTCP Sender Report (Section 6.4.1 of [RFC3550]). | format is same as the NTP timestamp field in the RTCP Sender | |||
Report (Section 6.4.1 of [RFC3550]). | ||||
The RTCP splicing notification message can be appended to RTCP SR the | The RTCP splicing notification message can be included in the RTCP | |||
main RTP sender generates in compound RTCP packets, and hence follows | compound packet together with RTCP SR generated at the main RTP | |||
the compound RTCP rules defined in Section 6.1 in [RFC3550]. | sender, and hence follows the compound RTCP rules defined in 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. | 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 | ||||
drift happening before the splicing event, it may be required to send | ||||
RTCP SR or even updated Splicing Interval information timely to | ||||
update the timestamp mapping for accurate splicing. | ||||
When the splicer intercepts the RTCP splicing notification message, | When the splicer intercepts the RTCP splicing notification message, | |||
it SHOULD NOT forward the message to the down-stream receivers in | it SHOULD NOT forward the message to the down-stream receivers in | |||
order to reduce RTCP bandwidth consumption. And if the splicer wishes | order to reduce RTCP bandwidth consumption. And if the splicer wishes | |||
to prevent the downstream receivers from detecting splicing, it MUST | to prevent the downstream receivers from detecting splicing, it MUST | |||
NOT forward the message. | NOT forward the message. | |||
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 | |||
skipping to change at page 12, line 5 ¶ | skipping to change at page 13, line 5 ¶ | |||
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 | |||
Only codecs that are supported both by the main RTP stream and the | ||||
substitutive RTP stream could be negotiated with SDP O/A. And the | ||||
splicer MUST choose the same codec for both of these two streams. | ||||
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 the | |||
BUNDLE group. | 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, | |||
skipping to change at page 15, line 27 ¶ | skipping to change at page 16, line 23 ¶ | |||
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 [RFC5285] apply. The | the general mechanism for RTP header extensions [RFC5285] apply. The | |||
splicer MUST either be a mixer or a translator, and has all the | splicer can either be a mixer or a translator, and has all the | |||
security considerations on these two standard RTP intermediaries. | security considerations on these two standard RTP intermediaries. | |||
However, the splicer replaces some content with other content in RTP | However, the splicer replaces some content with other content in RTP | |||
packet, thus breaking any RTP-level end-to-end security, such as | packet, thus breaking any RTP-level end-to-end security, such as | |||
source authentication and integrity protection. | source authentication and integrity protection. | |||
End to end source authentication is not possible with any known | End to end source authentication is not possible with any known | |||
existing splicing solution. A new solution can theoretically be | existing splicing solution. A new solution can theoretically be | |||
developed that enables identifying the participating entities and | developed that enables identifying the participating entities and | |||
what each provides, i.e., the different media sources, man and | what each provides, i.e., the different media sources, main and | |||
substituting, and the splicer providing the RTP-level integration of | substituting, and the splicer providing the RTP-level integration of | |||
the media payloads in a common timeline and synchronization context. | the media payloads in a common timeline and synchronization context. | |||
Since the mechanism introduced in this document is not dependent on | Since splicer works as a trusted entity, any RTP-level or outside | |||
any RTP payload-level hints for finding the splicing in and out | security mechanism, such IPsec[RFC4301] or Datagram Transport Layer | |||
points, Secure Real-Time Transport Protocol (SRTP) [3711] can be used | Security [RFC6347], will use a security association between the | |||
to provide confidentiality of the RTP payload while leaving the RTP | splicer and the receiver. When using the Secure Real-Time Transport | |||
header in the clear so that the splicer can still carry out splicing | Protocol (SRTP) [RFC3711], the splicer could be provisioned with the | |||
without keying materials. However, for a malicious endpoint without | same security association as the main RTP sender. | |||
the key, it can observe the splicing time in the RTP header, and it | ||||
can intercept the substitutive content and even replace it with a | ||||
different one if the substitutive stream does not use any security | ||||
like SRTP and the splicer does not authenticate the main and | ||||
substitutive content sources. | ||||
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, header extension encryption [RFC6904] SHOULD be used. | |||
However, the malicious endpoint may get the splicing time information | However, the malicious endpoint may get the splicing time information | |||
by other means, e.g., inferring from the communication between the | by other means, e.g., inferring from the communication between the | |||
main and substitutive content sources. To avoid the insertion of | main and substitutive content sources. To avoid the insertion of | |||
invalid substitutive content, the splicer MUST have some mechanisms | invalid substitutive content, the splicer MUST have some mechanisms | |||
to authenticate the substitutive stream source. | 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 | |||
skipping to change at page 17, line 36 ¶ | skipping to change at page 18, line 27 ¶ | |||
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. | ||||
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)", | |||
RFC 3711, March 2004. | RFC 3711, March 2004. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
End of changes. 22 change blocks. | ||||
66 lines changed or deleted | 108 lines changed or added | |||
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |