Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt

From: "Ben Campbell" <[email-masked]>
Date: Thu, 14 Jan 2016 16:48:14 -0600

Hi Rachel,

If I understand correctly, only one of your comments seemed to need a 
response from me. Please see below.

Thanks!

Ben.

On 22 Dec 2015, at 20:02, Huangyihong (Rachel) wrote:

[...]

>>>>> - 5:
>>>>> -- 3rd paragraph: The text "If a mixer works as the splicer
>>>>> [RFC6828]
>>>>> still seems to depend on RFC 6828 to define what a splicer is.
>
>>>>
>>>> [Rachel]: How about the following changing:
>>>>
>>>> " If a mixer works as the splicer as described in [RFC6828] and it
>>>> follows
>>>> [RFC3550], "
>
>
>>
>> Let's back up on this a bit. A reference needs to be normative if a
>> reader needs to read that reference to understand and/or implement 
>> the
>> protocol. If a reader doesn't read 6828, they will probably not
>> understand this paragraph. Is that important for understanding and
>> implementing the draft in general? (I think it probably is at least
>> somewhat important.) Can you restate the paragraph in a way that
>> describes the concept even if the reader doesn't read 6828? (It's 
>> okay
>> to use it as an example, as long as the reader can likely understand
>> things without the example.)
>>
>>
>
>
> [Rachel]: How about following proposed rephrasing?
> OLD
> "
> If a mixer works as the splicer [RFC6828] and it follows [RFC3550],
> the RTP sender whose content is being passed to a downstream receiver
> will see the reception quality of its stream as received by the mixer
> and the reception quality of the processed stream as received by the
> receiver; The RTP sender whose content is not being passed to a
> downstream receiver will only see the reception quality of its stream
> as received by the mixer. In such a case, the main RTP sender can
> learn that splicing failed if it still sees the RTCP RR packets sent
> from downstream receivers when the splicing starts; In a similar
> manner, the substitutive sender can also learn that splicing failed
> if it does not receive any RTCP RR packets from downstream receivers
> when the splicing starts.
>
> Other cases where senders and receivers are in different RTCP domains
> may require translation of RTCP reports, or additional reporting, if
> the senders want to detect splicing problems.
> "
>
> NEW
> "
> The splicer can be implemented to have its own SSRC, and send RTCP 
> reception reports to the senders of the main and substitutive RTP 
> streams. This allows the senders to detect problems on the path to the 
> splicer. Alternatively, it is possible to implement the splicer such 
> that it has no SSRC, and does not send RTCP reports; this prevents the 
> senders from being able to monitor the quality to the path to the 
> splicer.
>
> If the splicer has an SSRC and sends its own RTCP reports, it can 
> choose not to pass RTCP reports it receives from the receivers to the 
> senders. This will stop the senders from being able to monitor the 
> quality of the paths from the splicer to the receivers.
>
> A splicer that has an SSRC can choose to pass RTCP reception reports 
> from the receivers back to the senders, after modifications to account 
> for the splicing. This will allow the senders the monitor the quality 
> of the paths from the splicer to the receivers. A splicer that does 
> not have its own SSRC has to forward and translation RTCP reports from 
> the receiver, otherwise the senders will not see any receivers in the 
> RTP session.
>
> If the splicer is implemented following [RFC6828], it will have its 
> own SSRC and will send its own RTCP reports, and will forward 
> translated RTCP reports from the receivers.
> "

That works for me :-)

[...]

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 26 Jan 2016 08:22:16 +0000

Hi Ben,

Sorry for the late response. I was in a business trip during last several weeks. I'll update a new version soon to reflect the following discussions with you.

BR,
Rachel

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Friday, January 15, 2016 6:48 AM
> To: Huangyihong (Rachel)
> Cc: [email-masked]
> Subject: Re: [avtext] New Version Notification for
> draft-ietf-avtext-splicing-notification-03.txt
> 
> Hi Rachel,
> 
> >>>>> [RFC6828] still seems to depend on RFC 6828 to define what a
> >>>>> splicer is.
> >
> >>>>
> >>>> follows [RFC3550], "
> >> the protocol. If a reader doesn't read 6828, they will probably not
> >> okay to use it as an example, as long as the reader can likely
> >> understand things without the example.)
> >>
> >>
> >
> >
> > manner, the substitutive sender can also learn that splicing failed if
> > it does not receive any RTCP RR packets from downstream receivers when
> > the splicing starts.
> >

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 26 Jan 2016 09:19:44 -0600

No problem, thanks!

On 26 Jan 2016, at 2:22, Huangyihong (Rachel) wrote:

> Hi Ben,
>
> Sorry for the late response. I was in a business trip during last 
> several weeks. I'll update a new version soon to reflect the following 
> discussions with you.
>
> BR,
> Rachel
>
>>> if