--- 1/draft-ietf-mmusic-rtsp-nat-evaluation-03.txt	2011-10-27 14:14:05.706754812 +0200
+++ 2/draft-ietf-mmusic-rtsp-nat-evaluation-04.txt	2011-10-27 14:14:05.770756010 +0200
@@ -1,19 +1,19 @@
 
 Network Working Group                                      M. Westerlund
 Internet-Draft                                                  Ericsson
 Intended status: Informational                                   T. Zeng
-Expires: September 15, 2011                               March 14, 2011
+Expires: April 29, 2012                                 October 27, 2011
 
  The Evaluation of Different Network Addres Translator (NAT) Traversal
  Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
-                draft-ietf-mmusic-rtsp-nat-evaluation-03
+                draft-ietf-mmusic-rtsp-nat-evaluation-04
 
 Abstract
 
    This document describes several Network Address Translator (NAT)
    traversal techniques that was considered to be used by Real-time
    Streaming Protocol (RTSP).  Each technique includes a description on
    how it would be used, the security implications of using it and any
    other deployment considerations it has.  There are also disussions on
    how NAT traversal techniques relates to firewalls and how each
    technique can be applied in different use cases.  These findings
@@ -28,21 +28,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 September 15, 2011.
+   This Internet-Draft will expire on April 29, 2012.
 
 Copyright Notice
 
    Copyright (c) 2011 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
@@ -1048,24 +1048,24 @@
    could be increased.  To achieve a longer random tag while still using
    RTP and RTCP, it will be necessary to develop RTP and RTCP payload
    formats for carrying the random tag.
 
 4.3.5.  A Variation to Symmetric RTP
 
    Symmetric RTP requires a valid RTP format in the FW packet, which is
    the first packet that the client sends to the server to set up
    virtual RTP connection.  There is currently no appropriate RTP packet
    format for this purpose, although the No-Op format is a proposal to
-   fix the problem [I-D.ietf-avt-rtp-no-op].  There exist a document
-   that discusses the implication of different type of packets as keep-
-   alives for RTP [I-D.ietf-avt-app-rtp-keepalive] and its findings are
-   very relevant to the FW packet.
+   fix the problem [I-D.ietf-avt-rtp-no-op].  There exists a RFC that
+   discusses the implication of different type of packets as keep-alives
+   for RTP [RFC6263] and its findings are very relevant to the FW
+   packet.
 
    Meanwhile, there has been FW traversal techniques deployed in the
    wireless streaming market place that use non-RTP messages as FW
    packets.  This section attempts to summarize a subset of those
    solutions that happens to use a variation to the standard symmetric
    RTP solution.
 
    In this variation of symmetric RTP, the FW packet is a small UDP
    packet that does not contain RTP header.  Hence the solution can no
    longer be called symmetric RTP, yet it employs the same technique for
@@ -1564,27 +1564,20 @@
    are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,
    Amir Wolf, Anders Klemets, and Colin Perkins.  Thomas Zeng would also
    like to give special thanks to Greg Sherwood of PacketVideo for his
    input into this memo.
 
    Section Section 1.1 contains text originally written for RFC 4787 by
    Francois Audet and Cullen Jennings.
 
 10.  Informative References
 
-   [I-D.ietf-avt-app-rtp-keepalive]
-              Marjou, X. and A. Sollaud, "Application Mechanism for
-              keeping alive the Network Address Translator (NAT)
-              mappings associated to RTP/RTCP flows.",
-              draft-ietf-avt-app-rtp-keepalive-10 (work in progress),
-              March 2011.
-
    [I-D.ietf-avt-rtp-no-op]
               Andreasen, F., "A No-Op Payload Format for RTP",
               draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
 
    [I-D.ietf-mmusic-rfc2326bis]
               Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
               and M. Stiemerling, "Real Time Streaming Protocol 2.0
               (RTSP)", draft-ietf-mmusic-rfc2326bis-27 (work in
               progress), March 2011.
 
@@ -1645,20 +1638,24 @@
               October 2008.
 
    [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
               Relays around NAT (TURN): Relay Extensions to Session
               Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
 
    [RFC6062]  Perreault, S. and J. Rosenberg, "Traversal Using Relays
               around NAT (TURN) Extensions for TCP Allocations",
               RFC 6062, November 2010.
 
+   [RFC6263]  Marjou, X. and A. Sollaud, "Application Mechanism for
+              Keeping Alive the NAT Mappings Associated with RTP / RTP
+              Control Protocol (RTCP) Flows", RFC 6263, June 2011.
+
    [STUN-IMPL]
               "Open Source STUN Server and Client, http://
               www.vovida.org/applications/downloads/stun/index.html",
               June 2007.
 
 Authors' Addresses
 
    Magnus Westerlund
    Ericsson
    Farogatan 6