--- 1/draft-ietf-avtext-splicing-for-rtp-10.txt	2012-10-22 11:14:23.869342639 +0200
+++ 2/draft-ietf-avtext-splicing-for-rtp-11.txt	2012-10-22 11:14:23.901342612 +0200
@@ -1,18 +1,18 @@
 
 AVTEXT Working Group                                              J. Xia
 Internet-Draft                                                    Huawei
-Intended status: Informational                          October 10, 2012
-Expires: April 12, 2013
+Intended status: Informational                          October 22, 2012
+Expires: April 25, 2013
 
                    Content Splicing for RTP Sessions
-                 draft-ietf-avtext-splicing-for-rtp-10
+                 draft-ietf-avtext-splicing-for-rtp-11
 
 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.  Splicing is commonly used for local advertisement insertion by
    cable operators, replacing a national advertisement content with a
    local advertisement.
 
@@ -29,21 +29,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on April 12, 2013.
+   This Internet-Draft will expire on April 25, 2013.
 
 Copyright Notice
 
    Copyright (c) 2012 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -424,22 +424,23 @@
    RTCP packets received from downstream relate to the substitutive
    content must be terminated on the mixer without any further
    processing.
 
 4.3.  Considerations for Handling Media Clipping at the RTP Layer
 
    This section provides informative guideline about how media clipping
    is shaped and how the mixer deal with the media clipping only at the
    RTP layer.  Dealing with the media clipping at the RTP layer just do
    a good quality implementation, perfectly erasing the media clipping
-   needs more considerations in the higher layers, how to realize it is
-   outside of the scope of this memo.
+   needs more considerations at the higher layers, how the media
+   clipping is erased at the higher layers is outside of the scope of
+   this memo.
 
    If the time slot for substitutive content mismatches (is shorter or
    longer than) the duration of the main content to be replaced, then
    media clipping may occur at the splicing point and thus impact the
    user's experience.
 
    If the substitutive content has shorter duration from the main
    content, then there will be a gap in the output RTP stream.  The RTP
    sequence number will be contiguous across this gap, but there will be
    an unexpected jump in the RTP timestamp.  This gap will cause the
@@ -603,20 +604,23 @@
    invalidate the undetectability goal, but in the common case the
    receiver will consider the splicer as the main media source.
 
    Commonly no RTP level security mechanism is employed.  Instead only
    payload security mechanisms (e.g., ISMACryp [ISMACryp]) are used.  If
    any payload internal security mechanisms are used, only the RTP
    sender and the RTP receiver can learn the security keying material
    generated by such internal security mechanism, in which case, any
    middlebox (e.g., splicer) between the RTP sender and the RTP receiver
    can't get such keying material, and thus fail to perform splicing.
+   This would require a new method to be defined to make the splicer
+   learn the security keying material, but which is out of scope of this
+   memo.
 
 7.  IANA Considerations
 
    No IANA actions are required.
 
 8.  Acknowledgments
 
    The following individuals have reviewed the earlier versions of this
    specification and provided very valuable comments: Colin Perkins,
    Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R