Re: [avtext] Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)

["Huangyihong (Rachel)" <[e-mail]>]

Hi Alissa,

Thank you for the comments. Please see my replies inline.

BR,
Rachel, as one of the authors.

-----邮件原件-----
发件人: Alissa Cooper [mailto:[e-mail]] 
发送时间: 2016年6月15日 3:24
收件人: The IESG
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-avtext-splicing-notification-07: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 4 =

"Either the main RTP sender or the
   substitutive sender SHOULD send the synchronization metadata early
   enough so that the receivers can play out the multimedia in a
   synchronized fashion."

In Section 2 you gave a guideline for how to figure out how far in advance to send the splicing information. I think a similar guideline would be useful here. 

[Rachel]: Good point. I agree. So I suggest to add following sentences after the words you quoted.

"The main RTP sender or the substitutive sender can estimate when to send the synchronization metadata based on, for example, the round-trip time (RTT) following the
 mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender or the substitutive sender.
"

s/e.g., choosing media sender/e.g., choosing main RTP sender/

[Rachel]: Okay.

= Section 7 =

What is undetectable splicing?

[Rachel]: Undetectable splicing means that the RTP receivers should not be able to detect any splicing points in the RTP layer. It is required in some cases, for example, an IPTV advertisement user case, the service provider may want to make it difficult for the RTP receiver to detect where an advertisement insertion is starting or ending from the RTP packets, and thus avoiding the RTP receiver from filtering out the advertisement content.

= Section 8.3 =

In the past when we've registered these there was no contact I don't think. Not sure what IANA would do with one here.

[Rachel]: We'll remove the contact.