Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-splicing-for-rtp-00

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Nov 2010 18:38:27 +0800

Hi,

I have reviewed this draft and have some comments.

1. I find the requirements very difficult to support with standard RTP.
I think we need to discuss which ones are the least important ones and
which are the most important ones from the proponent.

2. I also think this draft fail to discuss on what signalling
requirements you have. How does the splicer related to the primary
stream source compared to the receiver?

3. What assumptions are made on how one can treat the primary stream. If
one splice in a ad instead of another at known locations in the stream
that is straight forward, but not really using the capabilities of a
packet based network, where pausing that stream would be more efficient.
What about VoD content that doesn't contain space, are you considering
pause and then replace?

More details on what use cases would be helping here.

4. As the splicer is an middlebox if one stays within the current RTP
architecture this is either an translator or a mixer.

Mixer: Incoming stream terminated in mixer, mixer selects between main
input and alternative stream and provides output to receiver.

Splits the RTCP reporting to be divided, thus sender of main stream does
not see path between mixer and receiver. This is a bit of a problem as
the mixer is expected to respond to congestion downstream. The mixer is
not allowed to forward RTCP Receiver reports, but possibly one could do
a translator style of the reports or some upstream media control.

If one doesn't really want to make it visible that the splicing happens
it is allowed to skip the CSRC field as this is only a SHOULD.

Translator: This is a poor match when it comes to splicing due to that
media sources are supposed to keep their original identifier over the
translator, although representation can change.

To my understanding the translator version of this function would be to
have the translator start forwarding the primary flow without any
changes. Then when it is time to splice, terminate the primary flow at
translator and insert itself as RTCP generator. Then send the
alternative flow as a translated flow into the primary flows SSRC.
During the splicing translation the general characteristic for the
translator - receiver needs to be combined with the characteristic the
primary flow sees on the sender to translator path. Thus a difficult
translation.

I would lean towards a mixer solution, even if there are issues. This is
about choosing the least problematic.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Jinwei Xia <[email-masked]>
Date: Mon, 08 Nov 2010 22:59:34 +0800

Hi Magnus,

Thank your review. Please see my response inline.

----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Jinwei Xia" <[email-masked]>
Cc: "'IETF AVT WG'" <[email-masked]>
Sent: Monday, November 08, 2010 6:38 PM
Subject: Re: [AVT] FW: New Version Notification fordraft-xia-avt-splicing-for-rtp-00

> which are the most important ones from the proponent.

Right, for operator, it is reluctant to enable user to detect ad insertion, hence user may filter the ad content. IMHO the most important requirement is user invisible, the sequence number continuity, paylod type consistence etc all belong to this important requirement. Single one stream forwarding is basic requirement of splicing.

> stream source compared to the receiver?

I confess the signalling requirments are difficult to be defined. Actually I have not gotten any explicit requirements from operator, this is why we hesitate between mixer and translator as splicer.

> packet based network, where pausing that stream would be more efficient.

Sorry, do you mean that media is directly carried on fiber but not RTP packets?

> What about VoD content that doesn't contain space, are you considering

Currently I just take live streaming into account. In VoD, my personal opinion is splicer pauses the primary stream and resumes at the inserted point after the ad insertion is over.

> it is allowed to skip the CSRC field as this is only a SHOULD.

One question. If CSRC field is vain, loop detection may not be performed, right?

> alternative flow as a translated flow into the primary flows SSRC.

Exact!

> primary flow sees on the sender to translator path. Thus a difficult

Can you clarify what's meaning of characteristic? What's additional work needs to do on a standard tranlator?

> about choosing the least problematic.

Yes, we need to find the better one to direct operator how to perform targeted ad insertion on RTP session. Hope we can find the answer on Tursday :-)

Thank you!

Jinwei

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Nov 2010 10:14:43 +0800

> I confess the signalling requirments are difficult to be defined. Actually I have not gotten any explicit requirements from operator, this is why we hesitate between mixer and translator as splicer.

I think it is important that we do consider what type of signalling is
assumed here.

> Sorry, do you mean that media is directly carried on fiber but not RTP packets?

No, I am simple trying to understand how the indication and signalling
happens for when a stream should be spliced, and if that needs to happen
at particular boundaries. In addition if one expects to pause the
primary stream.

> Currently I just take live streaming into account. In VoD, my personal opinion is splicer pauses the primary stream and resumes at the inserted point after the ad insertion is over.

Ok, but do these live stream has place for ADs or are you overwritting
content without knowledge.

> One question. If CSRC field is vain, loop detection may not be performed, right?

Correct, however, I think a splicer need to have good knowledge, i.e.
signalling about the streams it handles so loops are not that likely.

> Can you clarify what's meaning of characteristic? What's additional work needs to do on a standard tranlator?

First of all there are in my view no standard translator. There are
different categories of translators. This one would share properties
when it comes to RTCP with transcoder translator. However, there might
be some extra complications due to that there are no correspondance
between the incoming primary stream and then outgoing spliced one. But,
proportional reporting needs to happen by the translator in the RTCP.

> Yes, we need to find the better one to direct operator how to perform targeted ad insertion on RTP session. Hope we can find the answer on Tursday :-)

I hope so too.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 12:16:24 +0800

> I have reviewed this draft and have some comments.
...
> 4. As the splicer is an middlebox if one stays within the current RTP architecture this is either an translator or a mixer.
> 
> Mixer: Incoming stream terminated in mixer, mixer selects between main input and alternative stream and provides output to receiver.
> 
> Splits the RTCP reporting to be divided, thus sender of main stream does not see path between mixer and receiver. This is a bit of a problem as the mixer is expected to respond to congestion downstream. The mixer is not allowed to forward RTCP Receiver reports, but possibly one could do a translator style of the reports or some upstream media control.
> 
> If one doesn't really want to make it visible that the splicing happens it is allowed to skip the CSRC field as this is only a SHOULD.
> 
> 
> Translator: This is a poor match when it comes to splicing due to that media sources are supposed to keep their original identifier over the translator, although representation can change.

Isn't that exactly what's wanted here?

> To my understanding the translator version of this function would be to have the translator start forwarding the primary flow without any changes. Then when it is time to splice, terminate the primary flow at translator and insert itself as RTCP generator. Then send the alternative flow as a translated flow into the primary flows SSRC. During the splicing translation the general characteristic for the translator - receiver needs to be combined with the characteristic the primary flow sees on the sender to translator path. Thus a difficult translation.

I suspect you're overcomplicating the problem. This seems like a textbook RTP translator where the content of the primary stream is replaced by the content to be inserted (which might come from a local file, an MPEG2-TS, another RTP stream, etc).

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Nov 2010 14:14:38 +0800

> Isn't that exactly what's wanted here?

Yes, but it is doing it in a way that has least other impact.

> I suspect you're overcomplicating the problem. This seems like a textbook RTP translator where the content of the primary stream is replaced by the content to be inserted (which might come from a l…

Maybe I am over complicating it. However, I am not certain unless I do
know a bit what assumptions are made on the signalling plane for this
solution. Also where the expected deployment are and its relation to the
original media source.

I wouldn't call it a text book translator. It is a combination of a
video switching Mixer for the RTP output stream, and transcoding RTCP
translator.

But, I do think we should document this to help clarify the different
implementations of RTP/RTCP middleboxes.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 14:20:23 +0800

> implementations of RTP/RTCP middleboxes.

Agreed. There's been enough discussion that we clearly need to document how to build one of these devices, even if there's no standards work needed.

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

---

From: David R Oran <[email-masked]>
Date: Tue, 9 Nov 2010 15:46:25 -0500

> I suspect you're overcomplicating the problem. This seems like a textbook RTP translator where the content of the primary stream is replaced by the content to be inserted (which might come from a l…
Yes, but there's the additional requirement for obfuscation: the receiver should not be able to tell that the content has been spliced.

There is also another kind of nasty secret here, which should probably be mentioned. In the kind of splicing system I think the author envisions, the "signaling" that a splice is needed actually occurs "in band" in the RFC2250 payloads through a standard known as SCTE135. That means the translator not only has to pick the splice point and swap content, it also has to *excise* the SCTE135 data from the original stream. Otherwise, the receiver just looks at the SCTE markers in the stream and he knows when the splice happens. 

Also, depending on how savvy the original encoder was (or some other "conditioning" box upstream), the translator may also have to either adjust MPEG2TS continuity counters and/or PTS/DTS offsets, or at least be sure to set the discontinuity bits so naive receivers don't barf. Legacy MPEG splicers do all of this, and more.  If the goal is to attempt to "beat the devil" by trying to do splicing entirely at the RTP level with none of the magic of current MPEG splicers, I suspect that we would be mostly wasting our time.

I'm not sure this requirement to diddle the original stream changes anything other than SRTP, which it would clearly break unless the translator is re-authenticating and possibly re-encrypting everything. I doubt however if anybody has a use case for SRTP for these legacy multicast RFC2250 style scenarios so that part doesn't worry me other than documenting where SRTP would be prolematic.

If we drop the obfuscation requirement of course the entire splicing problem becomes much easier and a straightforward translator fills the bill. But I suspect that isn't what the proponents of the work have in mind.

DaveO.

> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 10 Nov 2010 10:35:47 +0800

Hi Magnus,

> at particular boundaries. In addition if one expects to pause the

Yes, primary media source provides information when to splicing, it usually happen aftter a complete GOP is over. How to convey the inforamtion to splicer is currently out of scope.

> content without knowledge.

Please refer my above response.

> proportional reporting needs to happen by the translator in the RTCP.

Right! RTCP reception reports must correctly reflect the situation of the path between translator and receiver.

BR
Jinwei