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

From: Jinwei Xia <[email-masked]>
Date: Sat, 16 Oct 2010 10:06:07 +0800

Hi,

>From the discussion on IETF 78th, there were some misunderstandings of the
scope of splicing draft. So we discard previous problem statement draft
while initiate new solution draft. In this new draft, We emphysize content
insertion issue is indeed a RTP-generic rather than MPEG2 TS-specific. 

Hope the new draft can address most issues AVT concern, any comments are
very appreciated!

BR!

Jinwei 

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Saturday, October 16, 2010 9:58 AM
> To: [email-masked]
> Subject: New Version Notification for 
> draft-xia-avt-splicing-for-rtp-00
> 
> 
> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt 
> has been successfully submitted by Jinwei Xia and posted to 
> the IETF repository.
> 
> Filename:	 draft-xia-avt-splicing-for-rtp
> Revision:	 00
> Title:		 Content Splicing for RTP Sessions
> Creation_date:	 2010-10-16
> WG ID:		 Independent Submission
> Number_of_pages: 12
> 
> Abstract:
> This memo outlines RTP splicing.  Splicing is a process that 
> allows a new multimedia stream to be inserted into current 
> multimedia stream and to be conveyed to receiver for a period 
> of time.  This memo discusses the requirements of RTP 
> splicing.  In order to satisfy the requirements, this memo 
> lists several existing intermediary network elements as 
> alternatives and evaluates whether one of alternatives can be 
> used to perform RTP splicing.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Oct 2010 14:51:49 +0100

Hi Jinwei,

My impression is that this draft confuses the issue by focussing too much on scenarios where the content to be inserted is also delivered over RTP. Whether the content to be inserted is delivered as a real-time RTP stream or fetched from local file storage does not affect the insertion process, and so doesn't need to be mentioned in the draft. I still believe that a standard RTP translator is sufficient to solve this problem, although there may be useful things to say about how to efficiently implement such a translator. 

Colin

On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
> Hi,
> 
> From the discussion on IETF 78th, there were some misunderstandings of the scope of splicing draft. So we discard previous problem statement draft while initiate new solution draft. In this new draft, We emphysize content insertion issue is indeed a RTP-generic rather than MPEG2 TS-specific. 
> 
> Hope the new draft can address most issues AVT concern, any comments are very appreciated!
> 
> 
> BR!
> 
> Jinwei 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: Jinwei Xia <[email-masked]>
Date: Thu, 21 Oct 2010 14:33:25 +0800

Hi Colin,

Thank your comments. The scenario description is given in problem statements
draft, it is unnecessary to repeat that in this draft. 

Indeed, a standard translator can handle splicing without any extension, and
it still needs instructions from media source to implement splicing. 

I will update the draft according to our maillist discussion. Any commets
from others are also very appreciated!

Thank you
Jinwei

> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Wednesday, October 20, 2010 9:52 PM
> To: Jinwei Xia
> Cc: 'IETF AVT WG'
> Subject: Re: [AVT] FW: New Version Notification for 
> My impression is that this draft confuses the issue by 
> focussing too much on scenarios where the content to be 
> inserted is also delivered over RTP. Whether the content to 
> be inserted is delivered as a real-time RTP stream or fetched 
> from local file storage does not affect the insertion 
> process, and so doesn't need to be mentioned in the draft. I 
> still believe that a standard RTP translator is sufficient to 
> solve this problem, although there may be useful things to 
> say about how to efficiently implement such a translator. 
> 
> Colin
> 
> 
> > From the discussion on IETF 78th, there were some 
> misunderstandings of the scope of splicing draft. So we 
> discard previous problem statement draft while initiate new 
> solution draft. In this new draft, We emphysize content 
> >> has been successfully submitted by Jinwei Xia and posted 
> to the IETF 
> >> repository.
> >> 
> >> This memo outlines RTP splicing.  Splicing is a process 
> that allows a 
> >> new multimedia stream to be inserted into current 
> multimedia stream 
> >> and to be conveyed to receiver for a period of time.  This memo 
> >> discusses the requirements of RTP splicing.  In order to 
> satisfy the 
> >> requirements, this memo lists several existing 
> intermediary network 
> >> elements as alternatives and evaluates whether one of alternatives 
> >> can be used to perform RTP splicing.
> >> 
> >> 
> >> 
> >> 
> >> The IETF Secretariat.
> >> 
> >> 
> >

---

From: Roni Even <[email-masked]>
Date: Thu, 21 Oct 2010 08:56:34 +0200

Hi Colin,
I am not so sure about this being a regular RTP translator. According To RFC
5117 " A Translator always keeps the SSRC for a stream across the
translation".
Also in the splicing case it is not point to point or multipoint but more
like multipoint to point or multipoint. This looks more like a mixer that
does not provide the CSRC since one of the requirements is to make it look
to the receiver that all the media is coming from the same source.
One issue that will need to be addressed is how to report the RTCP RR from
the receivers back to the sender of the primary or insertion streams. This
may need some state keeping in the splicer.

Roni Even 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Colin Perkins
> Sent: Wednesday, October 20, 2010 3:52 PM
> To: Jinwei Xia
> Cc: 'IETF AVT WG'
> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
> splicing-for-rtp-00
> 
> Hi Jinwei,
> 
> My impression is that this draft confuses the issue by focussing too
> much on scenarios where the content to be inserted is also delivered
> over RTP. Whether the content to be inserted is delivered as a real-
> time RTP stream or fetched from local file storage does not affect the
> insertion process, and so doesn't need to be mentioned in the draft. I
> still believe that a standard RTP translator is sufficient to solve
> this problem, although there may be useful things to say about how to
> efficiently implement such a translator.
> 
> Colin
> 
> 
> > From the discussion on IETF 78th, there were some misunderstandings
> of the scope of splicing draft. So we discard previous problem
> statement draft while initiate new solution draft. In this new draft,
> We emphysize content insertion issue is indeed a RTP-generic rather
> than MPEG2 TS-specific.
> >

---

From: Colin Perkins <[email-masked]>
Date: Thu, 21 Oct 2010 18:22:41 +0100

Hi Roni,

I think this problem becomes clearer if you consider a splicer that is reading the content to be inserted from a local file on disk. In that case, the splicer is unquestionably a standard RTP translator, in the middle of a one-to-one or one-to-many RTP session. 

That there are also some cases where an entirely separate RTP session is used to deliver the content to be inserted doesn't (conceptually) affect the translation process at all. 

Colin

On 21 Oct 2010, at 07:56, Roni Even wrote:
> Hi Colin,
> I am not so sure about this being a regular RTP translator. According To RFC 5117 " A Translator always keeps the SSRC for a stream across the translation". Also in the splicing case it is not point to point or multipoint but more like multipoint to point or multipoint. This looks more like a mixer that does not provide the CSRC since one of the requirements is to make it look to the receiver that all the media is coming from the same source. One issue that will need to be addressed is how to report the RTCP RR from the receivers back to the sender of the primary or insertion streams. This may need some state keeping in the splicer.
> 
> Roni Even 
> 
>> My impression is that this draft confuses the issue by focussing too much on scenarios where the content to be inserted is also delivered over RTP. Whether the content to be inserted is delivered as a real- time RTP stream or fetched from local file storage does not affect the insertion process, and so doesn't need to be mentioned in the draft. I still believe that a standard RTP translator is sufficient to solve this problem, although there may be useful things to say about how to efficiently implement such a translator.
>> 
>> Colin
>> 
>>

---

From: Roni Even <[email-masked]>
Date: Thu, 21 Oct 2010 20:26:18 +0200

Hi Colin,
In this use case the inserted content is not an RTP stream but comes from a
local storage. For this use case the splicer is a translator. It will still
need to handle the RTCP RR depending on who originated the data that was
sent by the translator.
My question will be if this is the typical use case or is there a use case
where the inserted data is not local and may arrive as RTP stream. In which
case there is more than one topology

Roni

> Sent: Thursday, October 21, 2010 7:23 PM
> To: Roni Even
> Cc: 'Jinwei Xia'; 'IETF AVT WG'
> I think this problem becomes clearer if you consider a splicer that is
> reading the content to be inserted from a local file on disk. In that
> case, the splicer is unquestionably a standard RTP translator, in the
> middle of a one-to-one or one-to-many RTP session.
> 
> That there are also some cases where an entirely separate RTP session
> is used to deliver the content to be inserted doesn't (conceptually)
> affect the translation process at all.
> 
> Colin
> 
> 
> 
> > I am not so sure about this being a regular RTP translator. According
> To RFC 5117 " A Translator always keeps the SSRC for a stream across
> the translation". Also in the splicing case it is not point to point or
> multipoint but more like multipoint to point or multipoint. This looks
> more like a mixer that does not provide the CSRC since one of the
> requirements is to make it look to the receiver that all the media is
> coming from the same source. One issue that will need to be addressed
> is how to report the RTCP RR from the receivers back to the sender of
> the primary or insertion streams. This may need some state keeping in
> the splicer.
> >
> > Roni Even
> >
> >>> Hope the new draft can address most issues AVT concern, any
> comments
> >> are very appreciated!
> >>>
> >>>
> >>> BR!
> >>>
> >>> Jinwei
> >>>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 21 Oct 2010 21:17:03 +0100

Roni,

I don't think it matters that the content arrives as an RTP stream. It's an entirely separate stream, and doesn't affect the translation process. They're logically separate.

Colin

On 21 Oct 2010, at 19:26, Roni Even wrote:
> Hi Colin,
> In this use case the inserted content is not an RTP stream but comes from a local storage. For this use case the splicer is a translator. It will still need to handle the RTCP RR depending on who originated the data that was sent by the translator.
> My question will be if this is the typical use case or is there a use case where the inserted data is not local and may arrive as RTP stream. In which case there is more than one topology
> 
> Roni
> 

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

---

From: David R Oran <[email-masked]>
Date: Thu, 21 Oct 2010 16:26:33 -0400

> I don't think it matters that the content arrives as an RTP stream. It's an entirely separate stream, and doesn't affect the translation process. They're logically separate.
I agree with Colin here. 

Either you treat the streams as equal inputs to a mixer, and the case reduces to the problem of a video mixer doing input switching, or you treat all the other inputs as external stuff that gets inserted into the main stream using a translator.

If you choose the mixer approach, you have to be a legal mixer, which means you keep state, use your own SSRC, and report CSRCs.

If you choose the translator approach, you have to "consume" the other stream and then emit it as if it were emitted by the original stream's source.

I don't see what the other approaches would be or how they might work better.

DaveO.

---

From: Roni Even <[email-masked]>
Date: Thu, 21 Oct 2010 22:47:08 +0200

Dave,
So the first question is if this is really one stream or is it two mixed
streams. My feeling was that it is two mixed streams and not one.

Now if it is two mixed streams than one of the requirements is that the
receiver will not identify which one is the inserted stream easily. So I am
not sure if CSRC is not contradictory.

I thought that we are talking here about a mixer but the case that Colin
provided when the inserted stream is local to splicer makes it more of a
translator except maybe the handling of the RTCP.

BTW: RTP translator and mixer are two of the topologies in RFC 5117, you can
also suggest that this is a Topo-RTCP-terminating-MCU doing video and audio
switch.

Roni Even

> From: David R Oran [mailto:[email-masked]]
> Sent: Thursday, October 21, 2010 10:27 PM
> To: Colin Perkins
> Cc: Roni Even; 'IETF AVT WG'
> > I don't think it matters that the content arrives as an RTP stream.
> It's an entirely separate stream, and doesn't affect the translation
> process. They're logically separate.
> >
> I agree with Colin here.
> 
> Either you treat the streams as equal inputs to a mixer, and the case
> reduces to the problem of a video mixer doing input switching, or you
> treat all the other inputs as external stuff that gets inserted into
> the main stream using a translator.
> 
> If you choose the mixer approach, you have to be a legal mixer, which
> means you keep state, use your own SSRC, and report CSRCs.
> 
> If you choose the translator approach, you have to "consume" the other
> stream and then emit it as if it were emitted by the original stream's
> source.
> 
> >> In this use case the inserted content is not an RTP stream but comes
> from a local storage. For this use case the splicer is a translator. It
> will still need to handle the RTCP RR depending on who originated the
> data that was sent by the translator.
> >> My question will be if this is the typical use case or is there a
> use case where the inserted data is not local and may arrive as RTP
> stream. In which case there is more than one topology
> >>
> >> Roni
> >>
> >>>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>> Of
> >>>>> Colin Perkins
> misunderstandings

---

From: David R Oran <[email-masked]>
Date: Thu, 21 Oct 2010 18:26:31 -0400

On Oct 21, 2010, at 4:47 PM, Roni Even wrote:

> receiver will not identify which one is the inserted stream easily.
So he can't skip ads, or something else?

> So I am
Interesting conundrum, no?

> also suggest that this is a Topo-RTCP-terminating-MCU doing video and audio
Right, in which case we're back to the CSRC-related conflicting goals.

---

From: Jinwei Xia <[email-masked]>
Date: Fri, 22 Oct 2010 11:30:15 +0800

Hi Dave,

Please see inline. 

> Behalf Of David R Oran
> Sent: Friday, October 22, 2010 4:27 AM
> To: Colin Perkins
> Cc: 'IETF AVT WG'; Roni Even
> Subject: Re: [AVT] FW: New Version Notification 
> fordraft-xia-avt-splicing-for-rtp-00
> 
> 
> > I don't think it matters that the content arrives as an RTP 
> stream. It's an entirely separate stream, and doesn't affect 
> the translation process. They're logically separate.
> > 
> I agree with Colin here. 
> 
> Either you treat the streams as equal inputs to a mixer, and 
> the case reduces to the problem of a video mixer doing input 
> switching, or you treat all the other inputs as external 
> stuff that gets inserted into the main stream using a translator.
> 
> If you choose the mixer approach, you have to be a legal 
> mixer, which means you keep state, use your own SSRC, and 
> report CSRCs.

 A standard mixer may not work well, it mix all the streams rather than
select one of them.

> 
> If you choose the translator approach, you have to "consume" 
> the other stream and then emit it as if it were emitted by 
> the original stream's source.

Translator acts as a client and terminate inserted stream from inserted
stream source view compared to acting as translator from original stream
source view.  But the RTCP RR issue mentioned by Roni is unsolved, I also
mark this issue as TBD in draft.  

> I don't see what the other approaches would be or how they 

MCU is not well defined in IETF, I agree to limit the scope in mixer and
translator.

> >> In this use case the inserted content is not an RTP stream 
> but comes from a local storage. For this use case the splicer 
> is a translator. It will still need to handle the RTCP RR 
> depending on who originated the data that was sent by the translator.
> >> My question will be if this is the typical use case or is 
> there a use 
> >> case where the inserted data is not local and may arrive as RTP 
> >>> I think this problem becomes clearer if you consider a 
> splicer that 
> >>> is reading the content to be inserted from a local file 
> on disk. In 
> >>> that case, the splicer is unquestionably a standard RTP 
> translator, 
> >>> in the middle of a one-to-one or one-to-many RTP session.
> >>> 
> >>> That there are also some cases where an entirely separate RTP 
> >>> session is used to deliver the content to be inserted doesn't 
> >>> (conceptually) affect the translation process at all.
> >>> 
> >>> Colin
> >>> 
> >>> 
> >>> 
> >>> the translation". Also in the splicing case it is not 
> point to point 
> >>> or multipoint but more like multipoint to point or 
> multipoint. This 
> >>> looks more like a mixer that does not provide the CSRC 
> since one of 
> >>> the requirements is to make it look to the receiver that all the 
> >>> media is coming from the same source. One issue that will 
> need to be 
> >>> addressed is how to report the RTCP RR from the receivers back to 
> >>> the sender of the primary or insertion streams. This may 
> need some 
> >>> state keeping in the splicer.
> >>>> 
> >>>> Roni Even
> >>>> 
> >>>>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> >>> Of
> >>>>> Colin Perkins
> focussing 
> >>>>> too
> >>> time RTP stream or fetched from local file storage does 
> not affect 
> >>> the insertion process, and so doesn't need to be mentioned in the 
> >>> draft. I still believe that a standard RTP translator is 
> sufficient 
> >>> to solve this problem, although there may be useful things to say 
> >>> about how to efficiently implement such a translator.
> >>>>> 
> >>>>> Colin
> >>>>> 
> >>>>> 
> >>>>> We emphysize content insertion issue is indeed a RTP-generic 
> >>>>> rather than MPEG2 TS-specific.
> >>>>>> 
> >>>>>>> has been successfully submitted by Jinwei Xia and 
> posted to the 
> >>>>>>> IETF repository.
> >>>>>>> 
> >>>>>>> multimedia stream and to be conveyed to receiver for 
> a period of 
> >>>>>>> time.  This memo discusses the requirements of RTP 
> splicing.  In 
> >>>>>>> order to satisfy the requirements, this memo lists several 
> >>>>>>> existing intermediary network elements as alternatives and 
> >>>>>>> evaluates whether one of alternatives can be used to 
> perform RTP 
> >>>>>>> splicing.
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> The IETF Secretariat.
> >>>>>>> 
> >>>>>>> 
> >>>>>> 
> >>>>>> Audio/Video Transport Working Group [email-masked]

---

From: David R Oran <[email-masked]>
Date: Fri, 22 Oct 2010 07:45:28 -0400

> A standard mixer may not work well, it mix all the streams rather than
Mixers are perfectly allowed to do simple stream selection/switching. Nearly all video "mixers" in fact do that rather than actually compositing or other forms of "mixing". I think you're being misled by the name.

> mark this issue as TBD in draft.  
Ok, but I'm still not seeing much of an issue.. Maybe I'm being naïve...

> MCU is not well defined in IETF, I agree to limit the scope in mixer and
Well, let's not get hung up too much on terminology; what's important is the function that have to be performed (or not performed), ensuring interoperability among the elements, and not making architectural changes to RTP unless no other approach satisfies the requirments.