Subject: [avtext] Consensus call on RTP Splicing direction forward

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Jun 2011 17:59:58 +0200

Hi,

We have had this ongoing discussion on the mailing list around the RTP
Splicing and the pro-and-cons for two major solutions. To try to get to
some decision on what the WG should focus on I would like to ask the WG
to indicate their preference for what should be done here. The options
are three on a high level. And this is for an informational document
that explains how you use the existing RTP features to accomplish splicing.

A) Focus only on RTP Translator based solution

B) Focus only on RTP Mixer based solution

C) Define both Mixer and Translator based solutions.

A) is pretty well described in the individual draft:
https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/

The trade-offs and limiations of A and B has been fairly well discussed
in the following email list discussion.
http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html

So if you aren't familiar with the topic already please review the above
and then indicate your position no later than the 26th of June.

Independently of the choice that solution will have to discuss the pros
and cons of that method and what properties it has.

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, 13 Jun 2011 09:59:51 +0800

Hi Chair,

Thank you for activing the item, I prefer to use translator for user
minimal-detectable case, i.e., option A.  The reason is mixer may get DoS
attack once its address is exposed for some vicious  users.

I will update the new version ASAP according to the conclusion of this
thread.

Thank you

Jinwei

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Saturday, June 11, 2011 12:00 AM
> To: [email-masked]
> Subject: [avtext] Consensus call on RTP Splicing direction forward
> 
> Hi,
> 
> We have had this ongoing discussion on the mailing list 
> around the RTP Splicing and the pro-and-cons for two major 
> solutions. To try to get to some decision on what the WG 
> should focus on I would like to ask the WG to indicate their 
> preference for what should be done here. The options are 
> three on a high level. And this is for an informational 
> document that explains how you use the existing RTP features 
> to accomplish splicing.
> 
> The trade-offs and limiations of A and B has been fairly well 
> discussed in the following email list discussion.
> So if you aren't familiar with the topic already please 
> review the above and then indicate your position no later 
> than the 26th of June.
> 
> Independently of the choice that solution will have to 
> discuss the pros and cons of that method and what properties it has.
> 
> Cheers
> 
> Magnus Westerlund
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: "Kevin Gross" <[email-masked]>
Date: Sun, 12 Jun 2011 21:33:54 -0600

I've reviewed the e-mails. I'm not certain I have a good grasp on the issue.
It appears the mixer (A) is the straightforward implementation. Why not go
with that?

The arguments for B or C seem to center around delectability. Detectability
seems to be slippery. If delectability is a concern, couldn't you just
insert, after the splicer, a translator with obfuscation level appropriate
for the application?

Kevin Gross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Magnus Westerlund
Sent: Friday, June 10, 2011 10:00 AM
To: [email-masked]
Subject: [avtext] Consensus call on RTP Splicing direction forward

Hi,

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Jun 2011 12:04:51 +0100

Hi,

On 10 Jun 2011, at 16:59, Magnus Westerlund wrote:
> We have had this ongoing discussion on the mailing list around the RTP Splicing and the pro-and-cons for two major solutions. To try to get to some decision on what the WG should focus on I would like to ask the WG to indicate their preference for what should be done here. The options are three on a high level. And this is for an informational document that explains how you use the existing RTP features to accomplish splicing.
> 
> The trade-offs and limiations of A and B has been fairly well discussed in the following email list discussion.
> So if you aren't familiar with the topic already please review the above and then indicate your position no later than the 26th of June.

I'm not convinced this is the right question to ask. A better question might focus on the requirement rather than the solution: do we describe how to do splicing in a way that's not detectable by the receiver, or in a way that allows the receiver to tell that content has been spliced in?

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Jun 2011 13:16:50 +0200

On 2011-06-13 13:04, Colin Perkins wrote:
> 
> I'm not convinced this is the right question to ask. A better
> question might focus on the requirement rather than the solution: do
> we describe how to do splicing in a way that's not detectable by the
> receiver, or in a way that allows the receiver to tell that content
> has been spliced in?
> 

Maybe, but my understanding from the discussion is that unless one does
media-transcoding, then it will be always possible to detect the splice.
Yes it can be difficult and need to include media cues and not 100%
accurate. But pretty well.

So the question regarding requirements one can ask is on the level of:

1) Clearly detectable in RTP

2) Likely not detectable in RTP level

And I think both A and B from the original question can accomplish
either of these. Thus, for the question of what track to aim I don't see
it as crucial question. For what the draft in the end contains, it is a
very important question. But I would prefer to take one question at a time.

Cheers

Magnus Westerlund

---

From: David R Oran <[email-masked]>
Date: Mon, 13 Jun 2011 10:33:34 -0400

Preference would be to start with (b) since it would be really helpful to have a complete description of splicing in a way that permits enough instrumentation to debug the system, and because most use cases do not in fact require non-detectability by receivers.

I have no objection to (c) since there is clearly interest in such a solution for those use cases requiring non-detectability, despite my personal skepticism about just how good a job can be done overall even if the RTP part succeeds at obfuscating the splices.

So, to summarize, work on mixer first and cone that's solid and well documented, figure out what instrumentation and debuggability, if any, we sacrifice in the process of doing a translator.

DaveO.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 14 Jun 2011 12:01:02 +0100

On 13 Jun 2011, at 12:16, Magnus Westerlund wrote:
> Maybe, but my understanding from the discussion is that unless one does media-transcoding, then it will be always possible to detect the splice. Yes it can be difficult and need to include media cues and not 100% accurate. But pretty well.

That depends on the codec being used, but I agree that you'll likely be able to see the splice in the media stream in many cases. 

> And I think both A and B from the original question can accomplish either of these. Thus, for the question of what track to aim I don't see it as crucial question. For what the draft in the end contains, it is a very important question. But I would prefer to take one question at a time.

A mixer-based solution could be detectable or non-detectable at the RTP layer, depending on whether a CSRC is included or not. Also, if we want to focus on a detectable solution, then there are other approaches to using mixers and translators that might be considered (e.g., something like a stream-switching MCU could also work).

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 14 Jun 2011 12:19:00 +0100

> So if you aren't familiar with the topic already please review the above and then indicate your position no later than the 26th of June.

Actually answering the question this time... :-)

If there is a requirement for non-detectability, which I understand the authors of draft-xia-avtext-splicing-for-rtp have, then I think that an RTP translator based solution is most appropriate, although an RTP mixer could also be made to work. 

If non-detectability is not a requirement, then a mixer based solution could make debugging easier (as Dave Oran has noted), and so might be more appropriate.

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

---

From: Jinwei Xia <[email-masked]>
Date: Thu, 16 Jun 2011 10:07:26 +0800

> Maybe, but my understanding from the discussion is that 
> unless one does media-transcoding, then it will be always 
> possible to detect the splice.
> Yes it can be difficult and need to include media cues and 
> not 100% accurate. But pretty well.
> 

Mixer can use CSRC list to facilitate debugging, so I agree Dave's option
that mixer is more appropriate in this case.

> 2) Likely not detectable in RTP level

translator is more complex to handle bitrate adaptation compared to mixer.
If using mixer without CSRC list, mixer has similar complexity, generating
timing and RTCP reports even when splicing is end, modifying sequence
numbers when main stream starts. Wheras translator only rewrites the
sequence numbers after first splicing.

So I littel incline to translator, but if the consensus of WG think mixer is
more appropriate, I'd like to follow the consensus.

> 
> And I think both A and B from the original question can 
> accomplish either of these. Thus, for the question of what 
> track to aim I don't see it as crucial question. For what the 
> draft in the end contains, it is a very important question. 
> But I would prefer to take one question at a time.

Can we choose C to address both cases or have to use two separated drafts
for each case? 

Thank you.

Jinwei

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 23 Jun 2011 11:25:27 +0200

[As WG chair]

Magnus sent out this call a couple of weeks back and we haven't seen very many responses.

If you have not already responded, please do so.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Magnus Westerlund
> Sent: 10 June 2011 17:00
> To: [email-masked]

---

From: Roni Even <[email-masked]>
Date: Thu, 23 Jun 2011 13:46:49 +0300

Hi,
I was inclining towards the mixer solution and having the CSRS information
optional depending if the RTP level splicing should be detectable easily.

I am not sure why not go to the C) solution since these will be an
Informational RFC and I think it may also add, as a side effect, some
information about RTP translators and Mixers.

Regards
Roni

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Friday, June 10, 2011 7:00 PM
> To: [email-masked]
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 6196 (20110610) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 6196 (20110610) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>