Subject: [avtext] Review of draft-ietf-avtext-splicing-notification-00

From: Colin Perkins <[email-masked]>
Date: Wed, 12 Nov 2014 16:48:52 +0000

Hi,

The chairs asked for review of the splicing-notification draft. I’ve read the earlier individual versions. Here are my comments on this version:

The draft defines a mechanism to convey splicing-in and splicing-out times for a stream using the RFC 6828 RTP splicing technique. The mechanism defined is a combination of a new RTP header extension and a new RTCP packet type. RFC 6828 requires some mechanism to convey the timing of the slicing interval, and this draft looks like a technically reasonable way of doing so.

This draft only considers how to convey the splicing interval from the sender to the splicing point, and not how to convey it to source of the substitutive content. I think this is acceptable. The substitutive sender needs clock synchronisation with the main sender, and to coordinate what content is to be spliced in, in addition to knowing when the splicing should occur. This suggests some detailed out-of-band signalling is needed, rather than a simple in-band time signal such as this.

I understand there is an MPEG-specific mechanism for conveying splicing times in-band in the media. This can clearly be used for MPEG transport sent in RTP, but the mechanism in the draft is more general since it can work with any RTP payload format. It also doesn’t require the splicer to parse the RTP payload when using MPEG transport. Both these seem like advantages.

Bo Burman sent comments about the use of the 24-bit splicing-out timestamp in the proposed RTP header extension. I agree that the text in the draft about this timestamp is incorrect and needs to be corrected, but think the timestamp is actually unambiguous given the specified constraints on the duration of the splicing period. That said, Bo’s proposal to use a delta timestamp would also work.

The draft says nothing about how often the header extension should be sent. I think that’s okay. It does have guidelines for how early to send it, although these would be better in Section 3.1 than their current place in Section 2.

End of section 3.2 “When the mixer intercepts the RTCP splicing notification message, it MAY NOT forward the message” ought to be “…SHOULD NOT forward…”?

The grouping mechanism in Section 6 looks okay to me, but should perhaps be reviewed by someone more familiar with SDP. Is the mechanism sufficient to handle splicing of bundled media? (e.g., if audio and video are sent bundled, and you want to splice in a replacement for just the audio)

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Nov 2014 00:55:59 +0000

(As WG cochair)

So we now have three reviews of this document (from Colin, Bo and Steve).

I would like the editors to respond to each of the reviews on list, and seek consensus on major issues in updating the document.

I assume Roni Even will provides some assistance in addressing the more editorial "use of english" aspects of the document.

Regards

Keith 

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of 
> Colin Perkins
> Sent: 12 November 2014 16:49
> To: [email-masked]
> Subject: [avtext] Review of draft-ietf-avtext-splicing-notification-00
> 
> Hi,
> 
> The chairs asked for review of the splicing-notification 
> draft. I've read the earlier individual versions. Here are my 
> comments on this version:
> 
> The draft defines a mechanism to convey splicing-in and 
> splicing-out times for a stream using the RFC 6828 RTP 
> splicing technique. The mechanism defined is a combination of 
> a new RTP header extension and a new RTCP packet type. RFC 
> 6828 requires some mechanism to convey the timing of the 
> slicing interval, and this draft looks like a technically 
> reasonable way of doing so.
> 
> This draft only considers how to convey the splicing interval 
> from the sender to the splicing point, and not how to convey 
> it to source of the substitutive content. I think this is 
> acceptable. The substitutive sender needs clock 
> synchronisation with the main sender, and to coordinate what 
> content is to be spliced in, in addition to knowing when the 
> splicing should occur. This suggests some detailed 
> out-of-band signalling is needed, rather than a simple 
> in-band time signal such as this.
> 
> I understand there is an MPEG-specific mechanism for 
> conveying splicing times in-band in the media. This can 
> clearly be used for MPEG transport sent in RTP, but the 
> mechanism in the draft is more general since it can work with 
> any RTP payload format. It also doesn't require the splicer 
> to parse the RTP payload when using MPEG transport. Both 
> these seem like advantages.
> 
> Bo Burman sent comments about the use of the 24-bit 
> splicing-out timestamp in the proposed RTP header extension. 
> I agree that the text in the draft about this timestamp is 
> incorrect and needs to be corrected, but think the timestamp 
> is actually unambiguous given the specified constraints on 
> the duration of the splicing period. That said, Bo's proposal 
> to use a delta timestamp would also work.
> 
> The draft says nothing about how often the header extension 
> should be sent. I think that's okay. It does have guidelines 
> for how early to send it, although these would be better in 
> Section 3.1 than their current place in Section 2.
> 
> End of section 3.2 "When the mixer intercepts the RTCP 
> splicing notification message, it MAY NOT forward the 
> message" ought to be "...SHOULD NOT forward..."?
> 
> The grouping mechanism in Section 6 looks okay to me, but 
> should perhaps be reviewed by someone more familiar with SDP. 
> Is the mechanism sufficient to handle splicing of bundled 
> media? (e.g., if audio and video are sent bundled, and you 
> want to splice in a replacement for just the audio)
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
>

---

From: Xiajinwei <[email-masked]>
Date: Thu, 13 Nov 2014 05:51:38 +0000

Chairs,

Thanks, we will respond the reviews and update a new version to address them soon.

Thanks

Jinwei

-----邮件原件-----
发件人: avtext [mailto:[email-masked]] 代表 DRAGE, Keith (Keith)
发送时间: 2014年11月13日 8:56
收件人: [email-masked]
主题: Re: [avtext] Review of draft-ietf-avtext-splicing-notification-00

(As WG cochair)

Regards

Keith 

> From: avtext [mailto:[email-masked]] On Behalf Of Colin 
> Perkins
> The chairs asked for review of the splicing-notification draft. I've 
> read the earlier individual versions. Here are my comments on this 
> version:
> 
> The draft defines a mechanism to convey splicing-in and splicing-out 
> times for a stream using the RFC 6828 RTP splicing technique. The 
> mechanism defined is a combination of a new RTP header extension and a 
> new RTCP packet type. RFC
> 6828 requires some mechanism to convey the timing of the slicing 
> interval, and this draft looks like a technically reasonable way of 
> doing so.
> 
> This draft only considers how to convey the splicing interval from the 
> sender to the splicing point, and not how to convey it to source of 
> the substitutive content. I think this is acceptable. The substitutive 
> sender needs clock synchronisation with the main sender, and to 
> coordinate what content is to be spliced in, in addition to knowing 
> when the splicing should occur. This suggests some detailed 
> out-of-band signalling is needed, rather than a simple in-band time 
> signal such as this.
> 
> I understand there is an MPEG-specific mechanism for conveying 
> splicing times in-band in the media. This can clearly be used for MPEG 
> transport sent in RTP, but the mechanism in the draft is more general 
> since it can work with any RTP payload format. It also doesn't require 
> the splicer to parse the RTP payload when using MPEG transport. Both 
> Bo Burman sent comments about the use of the 24-bit splicing-out 
> timestamp in the proposed RTP header extension.
> I agree that the text in the draft about this timestamp is incorrect 
> and needs to be corrected, but think the timestamp is actually 
> unambiguous given the specified constraints on the duration of the 
> splicing period. That said, Bo's proposal to use a delta timestamp 
> would also work.
> 
> The draft says nothing about how often the header extension should be 
> sent. I think that's okay. It does have guidelines for how early to 
> send it, although these would be better in Section 3.1 than their 
> current place in Section 2.
> 
> End of section 3.2 "When the mixer intercepts the RTCP splicing 
> notification message, it MAY NOT forward the message" ought to be 
> "...SHOULD NOT forward..."?
> 
> The grouping mechanism in Section 6 looks okay to me, but should 
> perhaps be reviewed by someone more familiar with SDP.
> Is the mechanism sufficient to handle splicing of bundled media? 
> (e.g., if audio and video are sent bundled, and you want to splice in 
> a replacement for just the audio)
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 20 Nov 2014 00:39:20 +0000

Hi Colin,

Thank you so much for you careful review. See some of my replies inline please.

BR,
Rachel

> From: avtext [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, November 13, 2014 12:49 AM
> To: [email-masked]
> The chairs asked for review of the splicing-notification draft. I've read the
> earlier individual versions. Here are my comments on this version:
> 
> The draft defines a mechanism to convey splicing-in and splicing-out times for a
> stream using the RFC 6828 RTP splicing technique. The mechanism defined is a
> combination of a new RTP header extension and a new RTCP packet type. RFC
> 6828 requires some mechanism to convey the timing of the slicing interval, and
> this draft looks like a technically reasonable way of doing so.

[Rachel] Thank you.
> 
> This draft only considers how to convey the splicing interval from the sender to
> the splicing point, and not how to convey it to source of the substitutive
> content. I think this is acceptable. The substitutive sender needs clock
> synchronisation with the main sender, and to coordinate what content is to be
> spliced in, in addition to knowing when the splicing should occur. This suggests
> some detailed out-of-band signalling is needed, rather than a simple in-band
> time signal such as this.
> 
> I understand there is an MPEG-specific mechanism for conveying splicing times
> in-band in the media. This can clearly be used for MPEG transport sent in RTP,
> but the mechanism in the draft is more general since it can work with any RTP
> payload format. It also doesn't require the splicer to parse the RTP payload
> when using MPEG transport. Both these seem like advantages.

[Rachel]: Exactly.

> 
> Bo Burman sent comments about the use of the 24-bit splicing-out timestamp
> in the proposed RTP header extension. I agree that the text in the draft about
> this timestamp is incorrect and needs to be corrected, but think the timestamp
> is actually unambiguous given the specified constraints on the duration of the
> splicing period. That said, Bo's proposal to use a delta timestamp would also
> work.

[Rachel]: We'll add some clarifications on this.

> 
> The draft says nothing about how often the header extension should be sent. I
> think that's okay. It does have guidelines for how early to send it, although
> these would be better in Section 3.1 than their current place in Section 2.

[Rachel]: Okay, will do.

> 
> End of section 3.2 "When the mixer intercepts the RTCP splicing notification
> message, it MAY NOT forward the message" ought to be "...SHOULD NOT
> forward..."?

[Rachel]: How about "MUST NOT"?

> 
> The grouping mechanism in Section 6 looks okay to me, but should perhaps be
> reviewed by someone more familiar with SDP. Is the mechanism sufficient to
> handle splicing of bundled media? (e.g., if audio and video are sent bundled,
> and you want to splice in a replacement for just the audio)

[Rachel]: I'm not quite familiar with BUNDLE. But doesn't the BUNDLE only deal with the unicast streams? For splicing, it's a multicast solution, and it's not using RFC3264 (offer/answer). So we think BUNDLE is not relevant.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Nov 2014 08:44:27 +0000

Hi Rachel,

On 20 Nov 2014, at 00:39, Huangyihong (Rachel) <[email-masked]> wrote:
> [Rachel]: How about “MUST NOT"?

I don’t think the recommendation needs to be that strong, since nothing breaks if the splicing notification is forwarded by a mixer (it’s just a minor information leakage). Using MUST NOT would work, but I think SHOULD NOT is closer to the intended semantic.

> [Rachel]: I'm not quite familiar with BUNDLE. But doesn't the BUNDLE only deal with the unicast streams? For splicing, it's a multicast solution, and it's not using RFC3264 (offer/answer). So we th…

There’s nothing to stop you splicing unicast content… 

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

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 20 Nov 2014 16:57:51 +0000

On Nov 12, 2014, at 11:48 AM, Colin Perkins <[email-masked]> wrote:

> The grouping mechanism in Section 6 looks okay to me, but should perhaps be reviewed by someone more familiar with SDP.

That’s a good point — I’ve requested an SDP directorate review of this document.

Jonathan (as AVTEXT co-chair)

---

From: "Roni Even" <[email-masked]>
Date: Fri, 21 Nov 2014 04:12:19 +0200

Hi,

> >> perhaps be reviewed by someone more familiar with SDP. Is the
> >> mechanism sufficient to handle splicing of bundled media? (e.g., if
> >> audio and video are sent bundled, and you want to splice in a
> >> replacement for just the audio)
> >
> > [Rachel]: I'm not quite familiar with BUNDLE. But doesn't the BUNDLE
only
> deal with the unicast streams? For splicing, it's a multicast solution,
and it's not
> using RFC3264 (offer/answer). So we think BUNDLE is not relevant.
> 
> There's nothing to stop you splicing unicast content.
[Roni Even] Bundle deal with offer/answer and I think that splicing is only
for declarative SDP.  If the mixer is not negotiation with all parties using
offer/answer he cannot bundle since will not know if supported. Maybe add
text that bundle is not supported

Anyhow for splicing only the video from a bundled audio and video, if want
to us offer/answer, maybe add that when bundling extmap is only for the
m-line that has it specified (according to
draft-ietf-mmusic-sdp-mux-attributes-04)

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Nov 2014 10:54:07 +0000

Hi Roni,

On 21 Nov 2014, at 02:12, Roni Even <[email-masked]> wrote:
>>> [Rachel]: I'm not quite familiar with BUNDLE. But doesn’t the BUNDLE only deal with the unicast streams? For splicing, it’s a multicast solution, and it’s not using RFC3264 (offer/answer). So we think BUNDLE is not relevant.
>> 
> [Roni Even] Bundle deal with offer/answer and I think that splicing is only for declarative SDP.  If the mixer is not negotiation with all parties using offer/answer he cannot bundle since will not know if supported. Maybe add text that bundle is not supported
> 
> Anyhow for splicing only the video from a bundled audio and video, if want to us offer/answer, maybe add that when bundling ext map is only for the m-line that has it specified (according to draft-ietf-mmusic-sdp-mux-attributes-04)

I don’t think it’s sufficient to say that splicing only works with declarative SDP. There’s nothing in the mechanism that would limit it to declarative or multicast sessions, so it ought to support OA and unicast.

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

---

From: "Roni Even" <[email-masked]>
Date: Sat, 22 Nov 2014 08:26:46 +0200

Hi,
In this case the document will need to say that the extmap for this header
extension when bundle is used has relevance only to the m-line in which it
is specified
Roni

> From: Colin Perkins [mailto:[email-masked]]
> Sent: 21 November, 2014 12:54 PM
> To: Roni Even
> Cc: Huangyihong (Rachel); [email-masked]
> Subject: Re: [avtext] Review of draft-ietf-avtext-splicing-notification-00
> 
> Hi Roni,
> 
> perhaps be reviewed by someone more familiar with SDP. Is the mechanism
> sufficient to handle splicing of bundled media? (e.g., if audio and video
are sent
> bundled, and you want to splice in a replacement for just the audio)
> >>>
only
and it's not
> > [Roni Even] Bundle deal with offer/answer and I think that splicing is
only for
> declarative SDP.  If the mixer is not negotiation with all parties using
> > Anyhow for splicing only the video from a bundled audio and video, if
want to
> us offer/answer, maybe add that when bundling ext map is only for the
m-line
> that has it specified (according to
> 
> I don't think it's sufficient to say that splicing only works with
declarative SDP.
> There's nothing in the mechanism that would limit it to declarative or
multicast
> sessions, so it ought to support OA and unicast.
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
>