Re: [avtext] WGLC for draft-ietf-avtext-splicing-notification-01

Dear Bo,

Many thanks to you for your careful reviewing and valuable comments. Please see my reply inline.

BR,
Rachel

> -----Original Message-----
> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman
> Sent: Friday, April 17, 2015 9:33 PM
> To: avtext@ietf.org
> Cc: draft-ietf-avtext-splicing-notification@tools.ietf.org
> Subject: Re: [avtext] WGLC for draft-ietf-avtext-splicing-notification-01
> 
> I have reviewed this draft, and I think that it addresses all of my previous
> concerns.
> 
> I have the following, additional comments to section 6:
> 
> 1) Is the intent that the main RTP stream in the SPLICE group is always the one
> with the splicing-interval extmap attribute, and the substitutive RTP is the
> other one? If so, I think being explicit about that could be helpful. You have
> marked that with an i= line in the example, but do not require it formally, and I
> also think you cannot require a parser to rely on i= information to choose which
> is which.

[Rachel]: Totally agree. We'll clarify it in the next version. The main stream is the one with the splicing-interval extmap attribute.

> 
> 2) I think it may be helpful to say that can there MUST NOT be more than two
> m-lines in a single SPLICE group. If there would be more, you obviously cannot
> know which RTP m-line to splice in at the splice point.

[Rachel]: Yes. Only 2 m-lines are allowed in a SPLICE group.

> 
> 3) I think it may be helpful to say that a single m-line MUST NOT be part of more
> than a single SPLICE group.

[Rachel]: Exactly. We'll clarify it in the next version.

> 
> 4) s/FID/SPLICE/

[Rachel]: Ok.

> 
> 5) In 6.3, SDP offer, should the substitutive video be sendonly, or is it
> intentionally sendrecv? It is sendrecv also in the SDP answer, so if it is
> intentional, it is formally OK between offer and answer.

[Rachel]: It should be sendonly.

> 
> 6) In 6.3, SDP answer, the substitutive audio is marked as sendonly, but should
> be recvonly to match the offer.

[Rachel]: Yes. You're right. Will fix it.

> 
> 7) Editorial nits:
> Near the end of section 2: s/sllowing/allowing/ Near beginning of section 6:
> s/This document extended/ This document extends/

[Rachel]: Okay. Thanks.

> 
> Cheers,
> Bo
> 
> > -----Original Message-----
> > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Jonathan
> > Lennox
> > Sent: den 31 mars 2015 16:27
> > To: avtext@ietf.org
> > Cc: avtext-chairs@tools.ietf.org;
> > draft-ietf-avtext-splicing-notification@tools.ietf.org
> > Subject: [avtext] WGLC for draft-ietf-avtext-splicing-notification-01
> >
> > This is to announce a 3 week Working Group Last Call for
> >
> > 	draft-ietf-avtext-splicing-notification-01
> >
> > as proposed standard.
> >
> > Please review and provide any comments you may have on the document by
> > Tuesday, April 21, 2015. Comments should be sent to the document
> > authors and the AVTEXT WG list. If you review the document but do not have
> any comments, please send a note to that effect as well.
> >
> > Please also forward this WGLC call to any other interested parties who
> > may be able to review the draft, asking them to also direct their comments to
> the authors and the list as above.
> >
> > Thank you!
> >
> >          Jonathan (AVTEXT co-chair)
> >
> >
> > Draft information:
> >
> >   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-01.txt
> > 	Pages           : 17
> > 	Date            : 2014-12-10
> >
> > 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 splicer is designed to handle RTP splicing and needs to
> >   know when to start and end the splicing.
> >
> >   This memo defines two RTP/RTCP extensions to indicate the splicing
> >   related information to the splicer: 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-notificati
> > on/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-01
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notificati
> > on-01
> >
> >
> > 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
> 
> _______________________________________________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext