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

[David R Oran <[e-mail]>]

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

> 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 he can't skip ads, or something else?

> So I am
> not sure if CSRC is not contradictory.
> 
Interesting conundrum, no?

> 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.
> 
Right, in which case we're back to the CSRC-related conflicting goals.

> Roni Even
> 
> 
> 
>> -----Original Message-----
>> From: David R Oran [mailto:[e-mail]]
>> Sent: Thursday, October 21, 2010 10:27 PM
>> To: Colin Perkins
>> Cc: Roni Even; 'IETF AVT WG'
>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
>> splicing-for-rtp-00
>> 
>> 
>> On Oct 21, 2010, at 4:17 PM, Colin Perkins wrote:
>> 
>>> 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.
>>> 
>> 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.
>> 
>>> 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:[e-mail]]
>>>>> 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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
>>>>>>>>> Sent: Saturday, October 16, 2010 9:58 AM
>>>>>>>>> To: [e-mail]
>>>>>>>>> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>>>> 
>>>>>>> --
>>>>>>> Colin Perkins
>>>>>>> http://csperkins.org/
>>>> 
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/avt
>>> 
>>> 
>>> 
>>> --
>>> Colin Perkins
>>> http://csperkins.org/
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/avt
>