Re: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-00.txt

I've reviewed this draft and have the following comments:

1) I'm lacking a discussion on why this solution is chosen, with splicing period information in RTP Header Extension and RTCP. What are the pro's/con's with it compared to other possible signaling solutions, external to RTP?

2) In section 3.1, I think the current specification of the splicing out NTP timestamp, seconds part, is broken, being just 24 bits. Assume that the splicing in point has an NTP timestamp seconds of (hex) 0xXXYYYYYY (XX being an arbitrary 8-bit number, YYYYYY a 24-bit number). If the difference between YYYYYY and 0x1000000 denotes a shorter time than the intended splicing interval, it will cause an increment in XX in the splicing out point NTP time. This invalidates the assumption that the upper 8 bits for the splicing out point are the same as the splicing in point. YYYYYY can in general be arbitrarily close to 0xFFFFFF, definitely not allowing a splicing interval of up to 2^25 seconds. For example, YYYYYY can be 0xFFFFFA, which causes a wrap in XX after only 6 seconds. It seems to me that the current text half-way assumes that the splicing out point is a delta time, which would in fact allow splicing times of up to 2^25 seconds. I suggest splicing out is instead specified as a delta time to the splicing in point (effectively being the length of the splicing period), in which case the above problems can be avoided. However, any carry digit from the sum of the splicing in and splicing period fractional parts must of course be used to adjust the seconds part of the resulting sum constituting the splicing out point. It could also be considered if RTCP splicing notification (in section 3.2) should then, for consistency, use the same splicing period instead of splicing out timestamp, but I have no specific preference there.

3) For section 3.2, is the best semantic and functional match a new RTCP report packet (see RFC 5968)? Was, for example, a new RTCP source description (SDES) type, describing a time period in the source RTP stream that can be replaced by a middle-node, considered? If it was considered and rejected, why?

4) In section 5, third and fourth paragraphs: it is somewhat opaque to me how RR from downstream receivers can help the main RTP sender and substitutive RTP sender learn that splicing did not occur? Downstream receivers will only see and report on the mixer's SSRC in either case, right? I think some clarification may be beneficial.

5) Are there any multicast/broadcast considerations that should be described, or will the scenario only work strictly point-to-point between (each of) the main RTP sender and the mixer, and the substitutive RTP sender and the mixer?

Editorial nits:
I) Section 2, second paragraph: "... more than once to against the possible packet loss" --> "... more than once to mitigate the possible packet loss "
II) Section 3.1, second paragraph: consumption --> assumption (if that text is kept after needed changes from 2 above)
III) Section 3.1, next-to-last paragraph: "could not include" --> "must not include"
IV) Section 4, title: Reduing --> Reducing
V) Section 6, second video m-line is lacking a=rtpmap

Cheers,
Bo

> -----Original Message-----
> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: den 29 juli 2014 15:15
> To: i-d-announce@ietf.org
> Cc: avtext@ietf.org
> Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF.
> 
>         Title           : RTP/RTCP Extension for RTP Splicing Notification
>         Authors         : Jinwei Xia
>                           Roni Even
>                           Rachel Huang
>                           Lingli Deng
> 	Filename        : draft-ietf-avtext-splicing-notification-00.txt
> 	Pages           : 12
> 	Date            : 2014-07-28
> 
> Abstract:
>    Content splicing is a process that replaces the content of a main
>    multimedia stream with other multimedia content, and delivers the
>    substitutive multimedia content to the receivers for a period of
>    time. The RTP mixer is designed to handle RTP splicing in [RFC6828],
>    but how the RTP mixer knows when to start and end the splicing is
>    still unspecified.
> 
>    This memo defines two RTP/RTCP extensions to indicate the splicing
>    related information to the RTP mixer: an RTP header extension that
>    conveys the information in-band and an RTCP packet that conveys the
>    information out-of-band.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are
> available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext