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

From: Jinwei Xia <[email-masked]>
Date: Tue, 02 Nov 2010 16:14:22 +0800

Hi Dave,

Sorry for my late response, I just come back from a business trip. Please
see inline.

[snip]

> > 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.
> > 
> Ok, but I'm still not seeing much of an issue.. Maybe I'm 
> being naïve...

During splicing, RTCP Receiver Reports only reflect the control information
of insertion content. In order to avoid the primary media sender to
misunderstand that its media stream disappears en route, Translator must
modify RR reception report blocks or fake new RRs prior to sending them to
media sender.  Is this a issue?

Thank you

Jinwei

> 
> >> 
> >> I don't see what the other approaches would be or how they 
> might work 
> >> better.
> > 
> > MCU is not well defined in IETF, I agree to limit the scope 
> in mixer 
> > and translator.
> > 
> 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.
> 
> 
> >> 
> >> DaveO.
> >> 
> >>> 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
> >>>> 
> >>>>> -----Original Message-----
> >>>>> From: Colin Perkins [mailto:[email-masked]]
> >>>>> Sent: Thursday, October 21, 2010 7:23 PM
> >>>>> To: Roni Even
> >>>>> Cc: 'Jinwei Xia'; 'IETF AVT WG'
> >>>>> Subject: Re: [AVT] FW: New Version Notification for
> >> draft-xia-avt-
> >>>>> splicing-for-rtp-00
> >>>>> 
> >>>>> 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
> >>>>>> 
> >>>>>>> -----Original Message-----
> >>>>>>> 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
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 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
> >>>>>>>> 
> >>>>>>>>> -----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.
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>> 
> >>>>>>>> _______________________________________________
> >>>>>>>> Audio/Video Transport Working Group [email-masked] 
> >>>>>>>> https://www.ietf.org/mailman/listinfo/avt
> >>>>>>> 
> >>>>>>> --
> >>>>>>> Colin Perkins
> >>>>>>> http://csperkins.org/
> >>>> 
> >>>> _______________________________________________
> >>>> Audio/Video Transport Working Group [email-masked] 
> >>>> https://www.ietf.org/mailman/listinfo/avt
> >>> 
> >>> 
> >>> 
> >>> --
> >>> Colin Perkins
> >>> http://csperkins.org/
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Audio/Video Transport Working Group
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/avt
> >> 
> >> 
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 2 Nov 2010 08:43:45 +0000

On 2 Nov 2010, at 08:14, Jinwei Xia wrote:
>>> 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.
>>> 
> During splicing, RTCP Receiver Reports only reflect the control information of insertion content. In order to avoid the primary media sender to misunderstand that its media stream disappears en route, Translator must modify RR reception report blocks or fake new RRs prior to sending them to media sender.  Is this a issue?

Isn't this just the standard behaviour mandated by RFC 3550?

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

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 02 Nov 2010 17:00:16 +0800

Hi Colin,

> Sent: Tuesday, November 02, 2010 4:44 PM
> To: Jinwei Xia
> Cc: IETF AVT WG
> Subject: Re: [AVT] FW: New Version 
> Notificationfordraft-xia-avt-splicing-for-rtp-00
> 
> >>> 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.
> >>> 
> >> Ok, but I'm still not seeing much of an issue.. Maybe I'm being 
> >> naïve...
> > 
> > During splicing, RTCP Receiver Reports only reflect the 
> control information of insertion content. In order to avoid 
> the primary media sender to misunderstand that its media 
> stream disappears en route, Translator must modify RR 
> reception report blocks or fake new RRs prior to sending them 
> to media sender.  Is this a issue?
> 
> 

RRs reflect the fraction lost of insertion content, does Translator need to
report these RRs to media sender?

Thank you

Jinwei

---

From: Colin Perkins <[email-masked]>
Date: Tue, 2 Nov 2010 09:18:19 +0000

On 2 Nov 2010, at 09:00, Jinwei Xia wrote:
> RRs reflect the fraction lost of insertion content, does Translator need to report these RRs to media sender?

The translator needs to modify the RRs from the downstream receivers to reflect the translation process before it sends them upstream to the sender. 

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

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 02 Nov 2010 17:35:35 +0800

> Sent: Tuesday, November 02, 2010 5:18 PM
> To: Jinwei Xia
> Cc: 'IETF AVT WG'
> >> 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.
> >>>>> 
> >> control information of insertion content. In order to avoid the 
> >> primary media sender to misunderstand that its media stream 
> >> disappears en route, Translator must modify RR reception report 
> >> blocks or fake new RRs prior to sending them to media sender.  Is 
> >> this a issue?
> >> 
> >> 
> > RRs reflect the fraction lost of insertion content, does 
> Translator need to report these RRs to media sender?
> 
> 
> The translator needs to modify the RRs from the downstream 
> receivers to reflect the translation process before it sends 
> them upstream to the sender. 

You are right, I am just not sure what's value are set in packet loss
fields. These translated values may be correctly reflect the actual
information.

BR
Jinwei