Subject: [avtext] Kathleen Moriarty's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 15 Jun 2016 11:37:34 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-avtext-splicing-notification-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I strongly support Mirja's and Alia's discuss points and would like to
see more of a discussion of the capability to hide splicing in the
security considerations text.  My ballot would be discuss, but they
pulled out the relevant sections and that would be duplication.  I'd like
to review agreed upon text though to address these concerns.  

I don't like the idea of enabling a MiTM, but do see the draft talks
about how to protect headers when this happens and confidentiality is
needed as well as session protection between the endpoints and the
splicer (which I don't like either, but you do call out the security
considerations of this and that's what is needed).

---

From: Colin Perkins <[email-masked]>
Date: Wed, 15 Jun 2016 23:34:33 +0100

> On 15 Jun 2016, at 19:37, Kathleen Moriarty <[email-masked]> wrote:
> 

The mechanism described doesn’t work unless the receiver explicitly chooses to receive media content delivered via the splicer. I agree that the draft could be more clearly written, but it doesn’t seem to be “enabling a MiTM” attack, since the receiver opts in.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 20 Jun 2016 11:29:13 +0200

Hi Colin,

see below.

> Am 16.06.2016 um 00:34 schrieb Colin Perkins <[email-masked]>:
> 

This definitely need from clarification in the draft!

Mirja

---

From: [email-masked]
Date: Mon, 20 Jun 2016 09:14:10 -0400

Sent from my iPhone

> On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Colin,
> 
> see below.
> 

Yes, can we see some proposed text?  

Thank you,
Kathleen

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 21 Jun 2016 12:58:16 +0000

Hi All,

Here's my proposal for addressing Alia's and other AD's similar DISCUSS. The main idea is to add a new subsection in Section 2, which is showed as following:

"
2.1 Overview of RTP Splicing

   RTP Splicing is to replace some multimedia content with certain
   substitutive multimedia content, and then forward it to the receivers
   for a period of time. This process is authorized by the service
   provider who sends the multimedia content to these receivers. A
   typical usage is that IPTV service providers use their own regional
   advertising content to replace national advertising content provided
   by the content providers.  

   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.

   The middle box working as the splicer is either a translator or a
   mixer. [RFC6828] specifies a splicer implemented as a mixer that uses
   its own SSRC, sequence number space, and timing model when generating
   the output stream to receivers. The mixer must not insert the SSRC of
   the main RTP stream or the SSRC of the substitutive RTP stream into
   the contributing source (CSRC) list in the output media stream when
   implementing undetectable splicing. Since it works as the mixer, it
   splits the RTCP flow between the sender and receiver into two
   separate RTCP loops. This implies additional considerations should be
   taken into account when handling congestion control, see Section 4.4
   of [RFC6828]. 

   A translator [RFC3550] can also be a splicer by forwarding the RTP packets with
   their SSRCs intact, where the congestion control runs between
   original sender and receiver, or between substitutive sender and
   receiver. In such a case, the RTCP feedback message must be passed to
   the right sender to let the congestion control work. And undetectable
   splicing will not be fulfilled when the translator works as the
   splicer.
"

Besides that, a new terminology is defined in section 1.1 to define "Undetectable Splicing", see below:

"
Undetectable Splicing:

The RTP receivers are not able to detect any splicing points in the RTP layer. Sometimes, service providers may require an undetectable splicing to avoid the RTP receivers from filtering out the advertisement content.

"

Your further thoughts or comments are welcomed. We'll bring a new version as soon as consensus is achieved.

BR,
Rachel

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, June 20, 2016 9:14 PM
> To: Mirja Kuehlewind (IETF)
> Cc: Colin Perkins; [email-masked];
> [email-masked]; [email-masked]; The IESG;
> [email-masked]
> Subject: Re: [avtext] Kathleen Moriarty's No Objection on
> draft-ietf-avtext-splicing-notification-07: (with COMMENT)
> 
> 
> 
> Sent from my iPhone
> 
> >>> On 15 Jun 2016, at 19:37, Kathleen Moriarty
> <[email-masked]> wrote:
> >>>
> >>> When responding, please keep the subject line intact and reply to
> >>> all email addresses included in the To and CC lines. (Feel free to
> >>> cut this introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> >>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>> I strongly support Mirja's and Alia's discuss points and would like
> >>> to see more of a discussion of the capability to hide splicing in
> >>> the security considerations text.  My ballot would be discuss, but
> >>> they pulled out the relevant sections and that would be duplication.
> >>> I'd like to review agreed upon text though to address these concerns.
> >>>
> >>> about how to protect headers when this happens and confidentiality
> >>> is needed as well as session protection between the endpoints and
> >>> the splicer (which I don't like either, but you do call out the
> >>> security considerations of this and that's what is needed).
> >>
> >> The mechanism described doesn’t work unless the receiver explicitly
> chooses to receive media content delivered via the splicer. I agree that the
> draft could be more clearly written, but it doesn’t seem to be “enabling a
> MiTM” attack, since the receiver opts in.
> >

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Jun 2016 14:32:11 -0500

Hi, some comments inline:

On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote:

> Hi All,
>
> Here's my proposal for addressing Alia's and other AD's similar 
> DISCUSS. The main idea is to add a new subsection in Section 2, which 
> is showed as following:
>
> "

I think this could be strengthened a bit. IIUC, this mechanism assumes 
the splicing interval is sent _by_ the main content provider. That is, 
this mechanism only works with the permission of the content provider. 
If they don't consent, they simply won't send the splicing interval.

This relationship might be more clear if the example talked about the 
main content provider offering a time window for the regional 
advertising insert, rather than about replacing national advertising. 
While that might in fact replace national content, it should be clear 
that the main provider _intends_ for the insert to happen.

>    implementing undetectable splicing.

I suggest promoting that last sentence a bit, and removing any hint of 
2119 language. For example:

"The splicer, operating on behalf of the content provider, may not wish 
to reveal that splicing has occurred. In this case, the splicer does not 
insert the SSRCs from either the main or substitutive RTP streams into 
the CSRC list in the resulting output media stream.."

> Since it works as the mixer, it
> The RTP receivers are not able to detect any splicing points in the 
> RTP layer. Sometimes, service providers may require an undetectable 
> splicing to avoid the RTP receivers from filtering out the 
> advertisement content.

That particular motivation gives me a bit of heartburn. But I think the 
reality is that the content provider wants to provide an apparently 
continuous stream, and they don't think the the splicing details are the 
business of the recipient (any more than the splices that occur in the 
original media stream incident to the normal editing of the content.)

>
> "
>
> Your further thoughts or comments are welcomed. We'll bring a new 
> version as soon as consensus is achieved.
>
> BR,
> Rachel
>
>
>>> On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) 
>>> <[email-masked]>
>> wrote:
>>>
>>> Hi Colin,
>>>
>>> see below.
>>>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 21 Jun 2016 17:36:26 -0400

This is useful clarification, but it still contains no hint that the
receiver has agreed.  It doesn't
alter the SHOULD or MUSTs associated with hiding this from receivers.

I am looking for a balanced explanation - the motivations here give me more
than heartburn.
It's clearly deciding for the content provider.

Regards,
Alia

On Tue, Jun 21, 2016 at 3:32 PM, Ben Campbell <[email-masked]> wrote:

>> Here's my proposal for addressing Alia's and other AD's similar DISCUSS.
>> The main idea is to add a new subsection in Section 2, which is showed as
>> following:
>>
>> "
> I think this could be strengthened a bit. IIUC, this mechanism assumes the
> splicing interval is sent _by_ the main content provider. That is, this
> mechanism only works with the permission of the content provider. If they
> don't consent, they simply won't send the splicing interval.
>
> This relationship might be more clear if the example talked about the main
> content provider offering a time window for the regional advertising
> insert, rather than about replacing national advertising. While that might
> in fact replace national content, it should be clear that the main provider
> _intends_ for the insert to happen.
>
>
> "The splicer, operating on behalf of the content provider, may not wish to
> reveal that splicing has occurred. In this case, the splicer does not
> insert the SSRCs from either the main or substitutive RTP streams into the
> CSRC list in the resulting output media stream.."
>
>> The RTP receivers are not able to detect any splicing points in the RTP
>> layer. Sometimes, service providers may require an undetectable splicing to
>> avoid the RTP receivers from filtering out the advertisement content.
>>
>
>>> On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) <
>>>> [email-masked]>
>>>>
>>> wrote:
>>>
>>>>
>>>> Hi Colin,
>>>>
>>>> see below.
>>>>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Jun 2016 16:45:35 -0500

> It's clearly deciding for the content provider.

I'm slightly confused. Why does the receiver have an interest in how the 
content provider composes content?

This is not (or at least should not be) a case where A produces content, 
B messes with it, and C wanted to receive the originally, un-messed-with 
content. It's a case where A provides content that happens to have 
real-time insertions at a splicer operating on A's behalf, and C 
receives it. One assumes C has the right to go somewhere else for their 
content, or maybe request a different, non-spliced stream if A is 
willing to provide it. But otherwise, why does C an interest in how A 
composes the stream?

I suppose there's a possibility for this to be truly abused--but the 
notification comes in the media stream between the content provider and 
the splicer, not from a third party. Obviously there are security 
considerations to make sure that's really true, but that is true for any 
media stream.

(It's entirely possible, nay even likely, that I am missing something. 
Maybe even a whole use case that looks more like a MiTM?)

Thanks!

Ben.

>>> DISCUSS.
>> main
>>>    A translator [RFC3550] can also be a splicer by forwarding the 
>>> RTP
>>> packets with
>>> RTP
>>>> [email-masked]; [email-masked]; 
>>>> The
>>>> IESG;
>>>> [email-masked]
>>>>> chooses to receive media content delivered via the splicer. I 
>>>>> agree
>>>> that the
>>>> draft could be more clearly written, but it doesn’t seem to be 
>>>> “enabling
>>>> a

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Jun 2016 00:46:12 +0300

Hi Alia,
I am not sure what you mean by "the receiver has agreed" agreed to what.
The receiver asked for content and he receives the content. Part of it is advertisements that are spliced in the stream.
The only consent I can think of may be in the application layer that may tell that this content include advertisements.  
What is hidden from the receiver is that some content is spliced in.
BTW: changing the content midstream without notifying the receiver can be done by any RFC3550 RTP mixer and this is why we have the reference to RFC7557.
Roni Even

> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, June 22, 2016 12:36 AM
> To: Ben Campbell
> Cc: Huangyihong; [email-masked]; Mirja Kuehlewind;
> Alissa Cooper; Colin Perkins; [email-masked]; draft-ietf-avtext-
> [email-masked]; [email-masked]; The IESG;
> [email-masked]
> Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS
> 
> This is useful clarification, but it still contains no hint that the receiver has
> agreed.  It doesn't alter the SHOULD or MUSTs associated with hiding this
> from receivers.
> 
> > "The splicer, operating on behalf of the content provider, may not
> > wish to reveal that splicing has occurred. In this case, the splicer
> > does not insert the SSRCs from either the main or substitutive RTP
> > streams into the CSRC list in the resulting output media stream.."
> >
> >> splicing to avoid the RTP receivers from filtering out the advertisement
> content.
> >>
> >
> > That particular motivation gives me a bit of heartburn. But I think
> > the reality is that the content provider wants to provide an
> > apparently continuous stream, and they don't think the the splicing
> > details are the business of the recipient (any more than the splices
> > that occur in the original media stream incident to the normal editing
> > of the content.)
> >
> >
> >
> >> "
> >>
> >>> The IESG; [email-masked]
> >>>>>> all email addresses included in the To and CC lines. (Feel free
> >>>>>> to cut this introductory paragraph, however.)
> >>>>>>
> >>>>>>
> >>>>>> Please refer to
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notif
> >>>>>> ica
> >>>>>> tion/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> >>>>>> ---
> >>>>>> --
> >>>>>> COMMENT:
> >>>>>> -----------------------------------------------------------------
> >>>>>> ---
> >>>>>> --
> >>>>>>
> >>>>>> I strongly support Mirja's and Alia's discuss points and would
> >>>>>> like to see more of a discussion of the capability to hide
> >>>>>> splicing in the security considerations text.  My ballot would be
> >>>>>> discuss, but they pulled out the relevant sections and that would be
> duplication.
> >>>>>> I'd like to review agreed upon text though to address these concern

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2016 22:52:32 +0100

> On 21 Jun 2016, at 22:46, Roni Even <[email-masked]> wrote:
…
> BTW: changing the content midstream without notifying the receiver can be done by any RFC3550 RTP mixer and this is why we have the reference to RFC7557.

To be clear: this can only be done if the receiver opts to receive content via that RTP mixer. The mixer is an application-level proxy, and there are defined end-to-end security mechanisms that can prevent unauthorised RTP mixers and translators from modifying the content, if such modification is considered a threat.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Jun 2016 16:53:26 -0500

On 21 Jun 2016, at 16:48, Colin Perkins wrote:

>> that occur in the original media stream incident to the normal 
>> editing of the content.)
>
>
> It’s implied, but perhaps easy to miss in Rachel’s suggested text, 
> that this is only talking about whether the splicing is detectable *at 
> the RTP layer*. A receiver that’s willing to analyse the metadata in 
> the payload can almost certainly tell that the content changed for the 
> duration of the splicing, even without decoding the video.

Okay, that's a good point. But one wonders why bother with the guidance 
for "undetectable splices" at all? In the example, if an implementation 
that wants to do commercial skipping can still do it anyway, then why 
even talk about it? (Other than to say that undetectable splices aren't 
real?)

Ben.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2016 22:57:45 +0100

> On 21 Jun 2016, at 22:53, Ben Campbell <[email-masked]> wrote:
> 
>>> That particular motivation gives me a bit of heartburn. But I think the reality is that the content provider wants to provide an apparently continuous stream, and they don't think the the splicing details are the business of the recipient (any more than the splices that occur in the original media stream incident to the normal editing of the content.)
>> 
>> 
>> It’s implied, but perhaps easy to miss in Rachel’s suggested text, that this is only talking about whether the splicing is detectable *at the RTP layer*. A receiver that’s willing to analyse the metadata in the payload can almost certainly tell that the content changed for the duration of the splicing, even without decoding the video.
> 
> Okay, that's a good point. But one wonders why bother with the guidance for "undetectable splices" at all? In the example, if an implementation that wants to do commercial skipping can still do it anyway, then why even talk about it? (Other than to say that undetectable splices aren't real?)

It (slightly) simplifies the receiver if it can not care about seeing multiple sources (either SSRC or CSRC, depending on how the splicer was implemented) in the RTP stream. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Alia Atlas <[email-masked]>
Date: Tue, 21 Jun 2016 18:07:14 -0400

Colin,

These are really useful points for me.
So, indicating that the receiver has agreed to receive the stream via the
splicer would help.
As written, it sounds like there is a requirement to hide the splicing from
the receiver - and all
the motivations I've been hearing are to "force" the receiver to get the
included advertisements
and not be able to tell where they are.

Regards,
Alia

On Tue, Jun 21, 2016 at 5:57 PM, Colin Perkins <[email-masked]> wrote:

> the reality is that the content provider wants to provide an apparently
> >> It’s implied, but perhaps easy to miss in Rachel’s suggested text, that
> this is only talking about whether the splicing is detectable *at the RTP
> layer*. A receiver that’s willing to analyse the metadata in the payload
> can almost certainly tell that the content changed for the duration of the
> splicing, even without decoding the video.
> >
> that wants to do commercial skipping can still do it anyway, then why even
> talk about it? (Other than to say that undetectable splices aren't real?)
>
> It (slightly) simplifies the receiver if it can not care about seeing
> multiple sources (either SSRC or CSRC, depending on how the splicer was
> implemented) in the RTP stream.
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2016 23:18:04 +0100

Alia,

> On 21 Jun 2016, at 23:07, Alia Atlas <[email-masked]> wrote:
> 
> Colin,
> 
> So, indicating that the receiver has agreed to receive the stream via the splicer would help.

You mean add something to the draft saying “the sender and receiver have to be explicitly configured to use the splicer”? Maybe also with some words in the security considerations explaining that there’s a signalling relationship between sender, splicer, and receiver that can be used to configure RTP-level security mechanisms to prevent modifications to the streams, or insertion of splicing notification messages by anyone other than the sender, if that’s considered a threat?

Colin

> As written, it sounds like there is a requirement to hide the splicing from the receiver - and all the motivations I’ve been hearing are to “force" the receiver to get the included advertisements and not be able to tell where they are.
> 
> Regards,
> Alia
> 
> On Tue, Jun 21, 2016 at 5:57 PM, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> > On 21 Jun 2016, at 22:53, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> >
> https://csperkins.org/ <https://csperkins.org/>
> 
> 
> 
> 
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2016 22:48:48 +0100

> On 21 Jun 2016, at 20:32, Ben Campbell <[email-masked]> wrote:
> 
> I think this could be strengthened a bit. IIUC, this mechanism assumes the splicing interval is sent _by_ the main content provider. That is, this mechanism only works with the permission of the content provider. If they don't consent, they simply won't send the splicing interval.
> 
> This relationship might be more clear if the example talked about the main content provider offering a time window for the regional advertising insert, rather than about replacing national advertising. While that might in fact replace national content, it should be clear that the main provider _intends_ for the insert to happen.

Right.

The other point that’s probably worth noting is that the receiver knows the traffic is being routed via the middlebox, and explicitly communicates with that middlebox via the RTCP reception reports it returns, and possibly also via some non-RTP signalling channel (the sender likely offers it no choice but to use the middlebox if it wants access to the media stream, but that’s a different issue…).

> I suggest promoting that last sentence a bit, and removing any hint of 2119 language. For example:
> 
> "The splicer, operating on behalf of the content provider, may not wish to reveal that splicing has occurred. In this case, the splicer does not insert the SSRCs from either the main or substitutive RTP streams into the CSRC list in the resulting output media stream.."
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 Jun 2016 17:40:36 -0500

On 21 Jun 2016, at 16:57, Colin Perkins wrote:

>>>> details are the business of the recipient (any more than the 
>>>> splices that occur in the original media stream incident to the 
>>>> normal editing of the content.)
>>>
>>>
>>> It’s implied, but perhaps easy to miss in Rachel’s suggested 
>>> text, that this is only talking about whether the splicing is 
>>> detectable *at the RTP layer*. A receiver that’s willing to 
>>> analyse the metadata in the payload can almost certainly tell that 
>>> the content changed for the duration of the splicing, even without 
>>> decoding the video.
>>
>> Okay, that's a good point. But one wonders why bother with the 
>> guidance for "undetectable splices" at all? In the example, if an 
>> implementation that wants to do commercial skipping can still do it 
>> anyway, then why even talk about it? (Other than to say that 
>> undetectable splices aren't real?)
>
> multiple sources (either SSRC or CSRC, depending on how the splicer 
> was implemented) in the RTP stream.

That may be the best motivation for not forwarding the input SSRCs 
offered so far.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jun 2016 23:43:13 +0100

Hi Colin,

On 21/06/16 22:48, Colin Perkins wrote:
> The other point that’s probably worth noting is that the receiver
> knows the traffic is being routed via the middlebox, and explicitly
> communicates with that middlebox via the RTCP reception reports it
> returns, and possibly also via some non-RTP signalling channel 

Sorry if I'm taking that out of context, but I don't understand the
above.

How does the receiver s/w know that it is interacting with a device
that is messing about with the content? I understood that it was in
fact a requirement here to make it hard for the receiver to be sure
of that.

I ask about the receiver s/w above, as clearly the warm body that
may have eyeballs pointed at content has no idea that the splicer is
in the path.

> (the
> sender likely offers it no choice but to use the middlebox if it
> wants access to the media stream, but that’s a different issue…)

Indeed

S.

.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2016 23:54:36 +0100

> On 21 Jun 2016, at 23:43, Stephen Farrell <[email-masked]> wrote:

My point was that the receiver has to be explicitly configured to get the media from the splicer, and the splicer can’t interpose itself in the media stream unless both sender and receiver chose to use it.

-- 
Colin Perkins
https://csperkins.org/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jun 2016 23:57:40 +0100

On 21/06/16 23:54, Colin Perkins wrote:
>> On 21 Jun 2016, at 23:43, Stephen Farrell
>> <[email-masked]> wrote: On 21/06/16 22:48, Colin Perkins
>> wrote:
>>> The other point that’s probably worth noting is that the
>>> receiver knows the traffic is being routed via the middlebox, and
>>> explicitly communicates with that middlebox via the RTCP
>>> reception reports it returns, and possibly also via some non-RTP
>>> signalling channel
>> 
>> Sorry if I'm taking that out of context, but I don't understand
>> the above.
>> 
>> How does the receiver s/w know that it is interacting with a
>> device that is messing about with the content? I understood that it
>> was in fact a requirement here to make it hard for the receiver to
>> be sure of that.
> 
> My point was that the receiver has to be explicitly configured

Well, not quite configured perhaps, more that it'd directed to
use the middlebox by something near the sender.

> to get
> the media from the splicer, and the splicer can’t interpose itself in
> the media stream unless both sender and receiver chose to use it.

Right. The receiver can't distinguish between a splicer and
some kind of relay that helps with getting around a f/w for
example.

So we need to be careful in saying what is "known."

S.

>> may have eyeballs pointed at content has no idea that the splicer
>> is in the path.
>> 
>>> (the sender likely offers it no choice but to use the middlebox
>>> if it wants access to the media stream, but that’s a different
>>> issue…)
>> 
>> Indeed
>> 
>> S.
>> 
>> .
>> 
> 
> 
>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 22 Jun 2016 02:59:17 +0000

Hi Colin and Ben,

Please see inline.

BR,
Rachel

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, June 22, 2016 5:49 AM
> To: Ben Campbell
> Cc: Huangyihong (Rachel); [email-masked]; Mirja
> Kuehlewind; Alia Atlas; Alissa Cooper; [email-masked];
> splicing interval is sent _by_ the main content provider. That is, this mechanism
> only works with the permission of the content provider. If they don't consent,
> they simply won't send the splicing interval.
> >
> content provider offering a time window for the regional advertising insert,
> rather than about replacing national advertising. While that might in fact
> replace national content, it should be clear that the main provider _intends_ for
> the insert to happen.
> 
> Right.

[Rachel]: According to your suggestions, how about changing the above text to below

"
   RTP Splicing is to replace some multimedia content with certain
   substitutive multimedia content, and then forward it to 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
   substitutive multimedia content in the main content. A typical usage
   is that a 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 other point that’s probably worth noting is that the receiver knows the
> traffic is being routed via the middlebox, and explicitly communicates with that
> middlebox via the RTCP reception reports it returns, and possibly also via some
> non-RTP signalling channel (the sender likely offers it no choice but to use the
> middlebox if it wants access to the media stream, but that’s a different
> issue…).

[Rachel]: Based on this suggestion, I propose to add a sentences in the end of the 2nd paragraph:

"
   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 traffic is routed via the splicer to the
   receivers. And the splicer is explicitly communicated with the
   receivers via RTCP packets and possibly via non-RTP signaling
   channel.
"

> reveal that splicing has occurred. In this case, the splicer does not insert the
> SSRCs from either the main or substitutive RTP streams into the CSRC list in the
> resulting output media stream.."

[Rachel]: Thanks for the suggestion.

> >> The RTP receivers are not able to detect any splicing points in the RTP layer.
> Sometimes, service providers may require an undetectable splicing to avoid the
> RTP receivers from filtering out the advertisement content.
> >
> > That particular motivation gives me a bit of heartburn. But I think the reality
> is that the content provider wants to provide an apparently continuous stream,
> and they don't think the the splicing details are the business of the recipient
> (any more than the splices that occur in the original media stream incident to
> the normal editing of the content.)
> 
> It’s implied, but perhaps easy to miss in Rachel’s suggested text, that this is
> only talking about whether the splicing is detectable *at the RTP layer*. A
> receiver that’s willing to analyse the metadata in the payload can almost
> certainly tell that the content changed for the duration of the splicing, even
> without decoding the video.
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 22 Jun 2016 03:13:21 +0000

Please see below.

BR,
Rachel

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, June 22, 2016 6:41 AM
> To: Colin Perkins
> >>> that this is only talking about whether the splicing is detectable
> >>> *at the RTP layer*. A receiver that’s willing to analyse the
> >>> metadata in the payload can almost certainly tell that the content
> >>> changed for the duration of the splicing, even without decoding the
> >>> video.
> >>
> That may be the best motivation for not forwarding the input SSRCs offered so
> far.

[Rachel]: I'm think if it's okay to not specify "undetectable splicing" in this document: This draft is to extend a RTP header extension and RTCP extension message for splicing interval, which is actually a message communicated between the sender and the splicer. So maybe we just need to specify that the splicer MUST NOT forward these extensions to the receivers, cause these messages are useless to them. For undetectable splicing, it has already been written in RFC6828, where splicer works as a mixer. If the splicer works as a translator, it's impossible for receivers not to detect the splicing happens in RTP layer. So I guess there's no need to specify any undetectable splicing activities in this document. What do you think?

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 22 Jun 2016 03:50:01 +0000

Hi Alia,

Please see below.

BR,
Rachel

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, June 22, 2016 6:07 AM
To: Colin Perkins
Cc: Ben Campbell; Huangyihong (Rachel); [email-masked]; Mirja Kuehlewind; Alissa Cooper; [email-masked]; [email-masked]; [email-masked]; The IESG; [email-masked]
Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS

Colin,

These are really useful points for me.
So, indicating that the receiver has agreed to receive the stream via the splicer would help.
As written, it sounds like there is a requirement to hide the splicing from the receiver - and all
the motivations I've been hearing are to "force" the receiver to get the included advertisements
and not be able to tell where they are.

[Rachel]: I guess undetectable splicing does cause some unhappiness. I suggest to remove it and related words from this document.
However, even not mentioning undetectable splicing, it still makes sense for the splicer to remove the header extension when forwarding the media content to the receivers, since the RTP sender intends to send the splicing interval messages to the splicer, not the receivers, and the splicer is on behalf of the RTP sender to forward the content. So in that case I don’t think it’s “hiding” or “force” the receive to get the advertisements. The time window is there, even there’s not substitutive advertisement spliced in, it still contains original advertisements.

Regards,
Alia

On Tue, Jun 21, 2016 at 5:57 PM, Colin Perkins <[email-masked]<mailto:[email-masked]>> wrote:
> On 21 Jun 2016, at 22:53, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
>

--
Colin Perkins
https://csperkins.org/

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Jun 2016 08:29:28 +0300

> Sent: Wednesday, June 22, 2016 1:55 AM
> To: Stephen Farrell
> Cc: Ben Campbell; [email-masked]; [email-masked]; Huangyihong;
> Alissa Cooper; [email-masked]; [email-masked];
> Mirja Kuehlewind; The IESG; [email-masked];
> Alia Atlas
> > fact a requirement here to make it hard for the receiver to be sure of
> > that.
> 
> My point was that the receiver has to be explicitly configured to get the
> media from the splicer, and the splicer can’t interpose itself in the media
> stream unless both sender and receiver chose to use it.
[Roni Even] This may also be a redirect by the source to splicer since this is where all the content is coming from
> 
> > I ask about the receiver s/w above, as clearly the warm body that may
> > have eyeballs pointed at content has no idea that the splicer is in
> > the path.
> >
> >> (the

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Jun 2016 10:08:25 -0500

On 21 Jun 2016, at 21:59, Huangyihong (Rachel) wrote:

[...]

>> insert,

I think that helps. I suggest the following (in the first sentence):

s/RTP Splicing is to replace.../RTP Splicing replaces...

(Or "RTP Splicing is intended to replace.."

>> knows the

Should the last sentence read "And the presence of the splicer..."?

Otherwise it looks good.

[...]

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Jun 2016 10:12:52 -0500

On 21 Jun 2016, at 22:13, Huangyihong (Rachel) wrote:

>>>>> text,
>> offered so
> [Rachel]: I'm think if it's okay to not specify "undetectable 
> splicing" in this document: This draft is to extend a RTP header 
> extension and RTCP extension message for splicing interval, which is 
> actually a message communicated between the sender and the splicer. So 
> maybe we just need to specify that the splicer MUST NOT forward these 
> extensions to the receivers, cause these messages are useless to them. 
> For undetectable splicing, it has already been written in RFC6828, 
> where splicer works as a mixer. If the splicer works as a translator, 
> it's impossible for receivers not to detect the splicing happens in 
> RTP layer. So I guess there's no need to specify any undetectable 
> splicing activities in this document. What do you think?

I'm generally okay with that, but I want to see what others think,

I do, though, wonder if the MUST NOT is still justified at this point. 
If the motivation is just that forwarding the messages are useless, or 
even a nuisance, MUST seems a bit strong. That is, it doesn't seem to 
impact interoperability, or otherwise create a real problem. This seems 
better stated without 2119 keywords.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 22 Jun 2016 12:16:20 -0400

Colin,

On Tue, Jun 21, 2016 at 6:18 PM, Colin Perkins <[email-masked]> wrote:

> You mean add something to the draft saying “the sender and receiver have
> to be explicitly configured to use the splicer”? Maybe also with some words
> in the security considerations explaining that there’s a signalling
> relationship between sender, splicer, and receiver that can be used to
> configure RTP-level security mechanisms to prevent modifications to the
> streams, or insertion of splicing notification messages by anyone other
> than the sender, if that’s considered a threat?
>

Yes - that would be useful.

My concern was triggered by the "undetectable splicing" and MUST NOTs
around letting the receiver know that the
splicing was happening.

Having some text that makes it clear that the receiver is a voluntary
participant and reducing suggestions to not forward the messages
to SHOULD NOT (or even MAY NOT or no fixed 2119 language) with an
explanation of this being to simplify the receiver would be very
helpful.

Regards,
Alia

> Colin
>
>
>
> As written, it sounds like there is a requirement to hide the splicing
> from the receiver - and all the motivations I’ve been hearing are to
> “force" the receiver to get the included advertisements and not be able to
> tell where they are.
>
> Regards,
> Alia
>
>> that this is only talking about whether the splicing is detectable *at the
>> RTP layer*. A receiver that’s willing to analyse the metadata in the
>> payload can almost certainly tell that the content changed for the duration
>> of the splicing, even without decoding the video.
>> >

---

From: Colin Perkins <[email-masked]>
Date: Wed, 22 Jun 2016 23:33:43 +0100

Hi Rachel,

One quick response inline.
Colin

> On 22 Jun 2016, at 03:59, Huangyihong (Rachel) <[email-masked]> wrote:
> 
> Hi Colin and Ben,
> 
> Please see inline.
> 
> BR,
> Rachel
> 
> 
> “

Yes, but the last sentence might be clearer if written something like “The receiver is explicitly configured to receive the traffic via the splicer, and will return any RTCP feedback to the splicer”.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 23 Jun 2016 02:25:36 +0000

> (Or "RTP Splicing is intended to replace.."

[Rachel]: Okay.

> Should the last sentence read "And the presence of the splicer..."?

[Rachel]: Okay. Based on Colin's suggestion, how about changing the last sentence to 

" In the presence of the splicer, the receiver is explicitly configured to receive the traffic via the splicer, and will return any RTCP feedback to it."

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 23 Jun 2016 02:45:36 +0000

BR,
Rachel

> If the motivation is just that forwarding the messages are useless, or even a
> nuisance, MUST seems a bit strong. That is, it doesn't seem to impact
> interoperability, or otherwise create a real problem. This seems better stated
> without 2119 keywords.

[Rachel]: Yes. MUST NOT can be changed to "should not". The intension is just to provide a guidance for implementing the splicer on how to deal with the splicing notification extension message when forwarding to the receivers.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Jun 2016 22:40:32 -0500

On 22 Jun 2016, at 21:25, Huangyihong (Rachel) wrote:

> " In the presence of the splicer, the receiver is explicitly 
> configured to receive the traffic via the splicer, and will return any 
> RTCP feedback to it."

WFM.