AVT                                                         F. Andreasen
Internet-Draft                                                   D. Oran
Expires: April 24, 2005                                          D. Wing
                                                     Cisco Systems, Inc.
                                                        October 24, 2004



                        RTP No-Op Payload Format
                       draft-wing-avt-rtp-noop-01


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   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."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on April 24, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This document defines an no-op payload format for the Real-time
   Transport Protocol (RTP), and a mechanism to request an immediate
   RTCP report.  This can be used to verify RTP connectivity and to keep
   Network Address Translator (NAT) bindings and Firewall pinholes open.


Requirements Language




Andreasen, et al.        Expires April 24, 2005                 [Page 1]


Internet-Draft          RTP No-Op Payload Format            October 2004



   The key words "MUST", "MUST NOT" "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  RTP Payload Format for No-Op . . . . . . . . . . . . . . . . .  3
     2.1   Registration . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2   Use of RTP Header Fields . . . . . . . . . . . . . . . . .  3
     2.3   Payload Format . . . . . . . . . . . . . . . . . . . . . .  4
     2.4   Sender Operation . . . . . . . . . . . . . . . . . . . . .  4
     2.5   Mixer, Translator Operation  . . . . . . . . . . . . . . .  4
     2.6   Receiver Operation . . . . . . . . . . . . . . . . . . . .  4
     2.7   Indication of No-OP Capability using SDP . . . . . . . . .  5
   3.  MIME Registration  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   audio/no-op  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   5.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.1   Normative References . . . . . . . . . . . . . . . . . . . .  7
   7.2   Informational References . . . . . . . . . . . . . . . . . .  8
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9



























Andreasen, et al.        Expires April 24, 2005                 [Page 2]


Internet-Draft          RTP No-Op Payload Format            October 2004



1.  Introduction


   This memo defines a new RTP payload format called "no-op".  This
   payload behaves like a normal RTP payload, except that it isn't
   played by the receiver.


   This new payload format is useful for:


   o  bearer continuity testing, such as at the beginning of a call;
   o  keepalives to keep NAT bindings open when RTP media traffic is not
      otherwise being transmitted;
   o  performing an RTP traceroute;


   For testing the RTP path, an RTP sender may transmit several No-Op
   payload packets with the Request Immediate RTCP bit set to 0,
   followed by one No-Op payload packet with the Request Immediate RTCP
   bit set to 1.  This would cause the RTP receiver to send an RTCP
   report indicating the quality of the RTP path.  The RTP sender could
   then decide to continue with call setup, abort the session, or
   perform some other action.


2.  RTP Payload Format for No-Op


   The no-op payload format is carried as part of the RTP stream, and
   MUST use the same sequence number space, SSRC, and timestamp base as
   the regular media.


2.1  Registration


   The RTP payload format is designated as "no-op" and the MIME type as
   "audio/no-op".  The default clock rate is 8000 Hz, but other rates
   MAY be used.  In accordance with current practice, this payload
   format does not have a static payload type number, but uses a RTP
   payload type number established dynamically and out-of-band.


2.2  Use of RTP Header Fields


   Timestamp: The RTP timestamp reflects the measurement point for the
      current packet.  The receiver calculates jitter for RTCP receiver
      reports based on all packets with a given timestamp.  Note: The
      jitter value should primarily be used as a means for comparing the
      reception quality between two users or two time-periods, not as an
      absolute measure.
   Marker bit: The RTP marker bit has no special significance for this
      payload type.







Andreasen, et al.        Expires April 24, 2005                 [Page 3]


Internet-Draft          RTP No-Op Payload Format            October 2004



2.3  Payload Format


   The payload format is shown below.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|                         reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      padding (OPTIONAL)                       |
      |                             ....                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The payload contains at least 4 bytes.  The first 32 bits are defined
   as follows:


   bit 0:      "R", "Request immediate RTCP", is used to request
               transmission of an immediate RTCP report (see Section
               2.6).
   bits 1-31:  Reserved; contents are ignored.


   Additional padding bytes MAY be appended up to the negotiated ptime
   value in SDP (see Section 2.6).  These bytes MUST contain all 0 bits.
   Padding may be useful to generate RTP packets that are the same size
   as a normal media payload.


2.4  Sender Operation


   A source MAY send normal RTP audio and the no-op payload format for
   the same time instants (but with different sequence numbers of
   course).  This might be done in conjunction with this payload
   format's "Request Immediate RTCP" opcode.


2.5  Mixer, Translator Operation


   An RTP mixer or unicast-to-unicast RTP translator SHOULD forward RTP
   No-Op payload packets normally.  A unicast-to-multicast RTP
   translator SHOULD replicate RTP No-Op payload packets normally.


   A multicast-to-unicast RTP translator SHOULD NOT replicate an RTP
   No-Op packet with the Request Immediate RTCP bit set, because the
   receivers won't be able to prevent flooding of the multicast RTP
   sender.


2.6  Receiver Operation


   Upon receipt of an RTP packet with the No-Op payload format and the
   Send Immediate RTCP Report bit set to 0, the receiver performs normal




Andreasen, et al.        Expires April 24, 2005                 [Page 4]


Internet-Draft          RTP No-Op Payload Format            October 2004



   RTP receive operations on it -- incrementing the RTP receive counter,
   calculating jitter, and so on.  The receiver then discards the packet
   -- it is not used to play out data.


   Upon receipt of an RTP packet with the No-Op payload format and the
   Send Immediate RTCP Report bit set to 1, the receiver performs the
   steps above and:


   o  if listening on a multicast IP address, the receiver MUST not send
      an immediate RTCP report, and the receiver MUST follow the normal
      RTCP transmission rules RFC3550, sections 6.2 and 6.3] [2], and
   o  if listening on a unicast IP address and sending RTP traffic, the
      receiver prepares to send an RTCP sender report, and
   o  if listening on a unicast IP address and receiving RTP traffic,
      the receiver prepares to send an RTCP receiver report.


   In all cases, before actually sending its RTCP report, the RTCP
   bandwidth limits and randomization interval MUST be observed RFC3550,
   sections 6.2 and 6.3 [2], most especially when multiple SSRCs are in
   the same session.


2.7  Indication of No-OP Capability using SDP


   Senders and receivers may indicate support for the No-Op payload
   format, for example, by using the Session Description Protocol SDP
   [3].


   If successful completion of RTP No-Op is required before completing
   call establishment -- such as to verify the existence or quality of
   the bearer path -- connectivity preconditions [4] can be used.


   The default packetization interval for this payload type is 20ms
   (ptime:20) but alternate values can be advertised in SDP using the
   ptime attribute value [3].


3.  MIME Registration


3.1  audio/no-op


   MIME media type name: audio


   MIME subtype name: no-op


   Required parameters: none


   Optional parameters: none


   Encoding considerations: This type is only defined for transfer via




Andreasen, et al.        Expires April 24, 2005                 [Page 5]


Internet-Draft          RTP No-Op Payload Format            October 2004



   RTP [2].


   Security considerations: See Section 4, "Security Considerations", in
   this document.


   Interoperability considerations: none


   Published specification: This document.


   Applications which use this media: The "no-op" audio subtype is used
   to maintain network state or verify network connectivity, when a more
   traditional RTP payload type cannot be used.


   Additional information:


   1.  Magic number(s): N/A
   2.  File extension(s): N/A
   3.  Macintosh file type code: N/A


4.  Security Considerations


   Without security of the RTP stream (via SRTP [6], IPsec [5], or other
   means), it is possible for an attacker to spoof RTP packets,
   including this new packet type.  As this new RTP payload type
   includes a method to request immediate transmission of RTCP, this
   could be used to cause endpoints to flood the network with RTCP
   reports.  Thus, the RTCP transmissions MUST NOT exceed the bandwidth
   recommendations described in section 6.3 of RFC3550 [2].


5.  Open Issues


   1.  Issues brought up during IETF59:
       A.  Roni Even asked why only the audio/noop MIME type is listed?
           The answer is that there is no reason for not having it for
           all media types in use.  The draft is simply missing
           registration of all the media types that are appropriate.
       B.  Dan Romascanu noted that it is not very clear from the draft
           how you can determine the actual media path characteristics
           through the use of RTCP, and how to separate the reception
           quality reports for the NOOP traffic from other media
           traffic.  Flemming noted that the RTP SSRC can be used to
           separate traffic, and promised to work on the text,
           clarifying this.
       C.  Magnus Westerlund and Colin Perkins noted that the draft is
           unclear on the interactions between its immediate feedback
           request and the usual RTCP timers (in both the standard A/V
           profile and in the RTCP feedback profile).  Clarification was
           requested.




Andreasen, et al.        Expires April 24, 2005                 [Page 6]


Internet-Draft          RTP No-Op Payload Format            October 2004



       D.  Jonathan Rosenberg was doubtful of the need to request
           immediate RTCP reports.  He supported the functionality of an
           RTP payload format that is discarded, to keep NAT bindings
           alive when media is on hold, but asked the group to consider
           the need for requesting immediate RTCP reports and to clarify
           the problem and requirements before jumping into the solution
           space.
       E.  Jonathan also noted, as he did in the MMUSIC session, that
           ICE and STUN would still be needed for NAT traversal, and so
           can't be replaced with this mechanism.
       F.  Roni Even also commented that the use case for checking the
           MTU might need feedback, however the QoS diagnostic does look
           like a different issue.
       G.  Colin Perkins concluded that the draft must be updated and
           clarified on use cases, and what problems it solves.
   2.  Discuss how this relates to AVPF.
   3.  Need to expand on the RTCP transmission interval considerations
       and explain in more detail when you can and cannot transmit
       (i.e., does not modify/violate normal RTCP considerations)
   4.  Should "request immediate RTCP" be a generic mechanism?
   5.  Clarify usefulness of Noop for diagnostics.
   6.  Clarify how the packet counting, etc.  works.  Should explain a
       bit more in document (e.g.  how everything is on a per SSRC
       basis, packet counting works and is revealed in the RTCP reports,
       etc.).  The document isn't clear on this.


6.  Acknowledgments


   Thanks to Henning Schulzrinne for suggesting using RTCP as a feedback
   mechanism.


7.  References


7.1  Normative References


   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.


   [2]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", STD 64,
        RFC 3550, July 2003.


   [3]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.


   [4]  Andreasen, F., "Connectivity Preconditions for Session
        Description Protocol Media Streams",
        draft-andreasen-mmusic-connectivityprecondition-00 (work in




Andreasen, et al.        Expires April 24, 2005                 [Page 7]


Internet-Draft          RTP No-Op Payload Format            October 2004



        progress), February 2004.


7.2  Informational References


   [5]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.


   [6]  Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K.
        Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
        3711, March 2004.



Authors' Addresses


   Flemming Andreasen
   Cisco Systems, Inc.
   499 Thornall Street, 8th Floor
   Edison, NJ  08837
   USA


   EMail: fandreas@cisco.com



   David Oran
   Cisco Systems, Inc.
   7 Ladyslipper Lane
   Acton, MA  01720
   USA


   EMail: oran@cisco.com



   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA


   EMail: dwing@cisco.com













Andreasen, et al.        Expires April 24, 2005                 [Page 8]


Internet-Draft          RTP No-Op Payload Format            October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.






Andreasen, et al.        Expires April 24, 2005                 [Page 9]


Internet-Draft          RTP No-Op Payload Format            October 2004



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































Andreasen, et al.        Expires April 24, 2005                [Page 10]