AVT                                                         F. Andreasen
Internet-Draft                                                   D. Oran
Intended status: Standards Track                                 D. Wing
Expires: October 29, 2007                            Cisco Systems, Inc.
                                                          April 27, 2007


                     A No-Op Payload Format for RTP
                      draft-ietf-avt-rtp-no-op-03

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 October 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines an no-op payload format for the Real-time
   Transport Protocol (RTP).  This packet is not played out by
   receivers.  It can be useful as a way to keep Network Address
   Translator (NAT) bindings and Firewall pinholes open.  Other uses are
   discussed in the document.





Andreasen, et al.       Expires October 29, 2007                [Page 1]


Internet-Draft          RTP No-Op Payload Format              April 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in this Document  . . . . . . . . . . . . . .  4
   3.  RTP Payload Format for No-Op . . . . . . . . . . . . . . . . .  4
     3.1.  Registration . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Use of RTP Header Fields . . . . . . . . . . . . . . . . .  4
     3.3.  Payload Format . . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Sender Operation . . . . . . . . . . . . . . . . . . . . .  5
     3.5.  Mixer, Translator Operation  . . . . . . . . . . . . . . .  5
     3.6.  Receiver Operation . . . . . . . . . . . . . . . . . . . .  6
     3.7.  Indication of No-OP Capability using SDP . . . . . . . . .  6
   4.  Example SDP Offer/Answer . . . . . . . . . . . . . . . . . . .  6
   5.  Media Type Registration  . . . . . . . . . . . . . . . . . . .  7
     5.1.  audio/no-op  . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  video/no-op  . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  text/no-op . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informational References . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12


























Andreasen, et al.       Expires October 29, 2007                [Page 2]


Internet-Draft          RTP No-Op Payload Format              April 2007


1.  Introduction

   This memo defines a new RTP payload format called "no-op".  This
   payload behaves like a normal RTP payload, except the RTP packet is
   not used to play out media.

   This new payload format is useful for:

   o  facilitating media session reception quality assessment, such as
      at the beginning of a session;

   o  keepalives to keep NAT bindings and/or firewall pinholes open when
      RTP media traffic is not otherwise being transmitted.

   o  measurement-based admission control by probing available
      bandwidth, and

   o  synthetic load generation for performance testing and other
      minimally-intrusive instrumentation.

   When an endpoint has a media stream marked as 'recvonly' or
   'inactive' the endpoint is not supposed to send any media (i.e., RTP
   packets).  However, to keep a NAT binding alive, the endpoint will
   need to periodically send packets over the RTP and RTCP ports.  RTP
   No-Op is ideally suited to this.  In comparison, if one participant
   in an audio multicast conference has a 'recvonly' or 'inactive' media
   stream yet occasionally sends comfort noise packets in order to keep
   its NAT binding open, these comfort noise packets are interpreted as
   audio packets by receivers and mixers which can cause undesirable
   behavior -- such as selection of the primary speaker or the playout
   of comfort noise when no audio should be played.

   Unlike Comfort noise [RFC3389], which is specific to voice RTP
   streams, RTP No-Op is applicable to any kind of RTP stream including
   video, audio, realtime text, or any other media types that would
   benefit from the capabilities listed above.  This gives RTP No-Op an
   advantage as a NAT keepalive mechanism.  Certain functions and RTP
   payload types can use RTP No-Op without re-inventing their own
   payload-specific NAT keepalive mechanism -- such as video muting,
   Clearmode [RFC4040], and text [RFC4103].

   Some audio codecs have their own 'silence' packets.  However, some
   codecs only send such silence packets if the noise floor changes;
   G.729b [G729B] is an example of such a codec.  RTP No-Op allows the
   RTP stack itself, rather than the codec, to send periodic packets as
   a keepalive mechanism.

   Multiplexing RTP and RTCP over the same port



Andreasen, et al.       Expires October 29, 2007                [Page 3]


Internet-Draft          RTP No-Op Payload Format              April 2007


   [I-D.ietf-avt-rtp-and-rtcp-mux] provides an separate keepalive
   mechanism which uses the periodic RTCP transmission to keep
   middleboxes aware of the flow.


2.  Conventions Used in this Document

   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 [RFC2119].


3.  RTP Payload Format for No-Op

3.1.  Registration

   The RTP payload format is designated as "no-op" and the MIME types
   are "audio/no-op", "video/no-op", and "text/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 out-of-band, e.g. through SDP [RFC4566].

3.2.  Use of RTP Header Fields

   Timestamp:  The RTP timestamp reflects the measurement point for the
      current packet.  The receiver uses this timestamp to calculate
      jitter for RTCP sender and receiver reports per normal RTP
      procedures.  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 October 29, 2007                [Page 4]


Internet-Draft          RTP No-Op Payload Format              April 2007


3.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      padding (OPTIONAL)                       |
      |                             ....                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1: Payload Format

   The payload contains at least 4 bytes, the first 32 bits are reserved
   for future use.  These bits SHOULD be set to 0.  Receivers MUST
   ignore the value of these bits.

   Additional padding bytes MAY be appended up to the ptime or maxptime
   value in SDP (see Section 3.7).  These bytes MUST be ignored.
   Padding may be useful to generate RTP packets that are the same size
   as a normal media payload.

3.4.  Sender Operation

   As discussed in the introduction, endpoints must occasionally send a
   packet to their RTP and RTCP peer to keep NAT and firewall bindings
   active, even if the media stream is marked 'recvonly' or 'inactive'.
   No matter if the media stream is marked 'recvonly', 'sendrecv',
   'sendonly', or 'inactive', if approximately 20 seconds elapse with no
   packets transmitted from the RTP port (either RTP packets or non-RTP
   packets (e.g., STUN [I-D.ietf-behave-rfc3489bis] packets), then an
   RTP No-Op packet SHOULD be sent.

3.5.  Mixer, Translator Operation

   An RTP mixer or unicast-to-unicast RTP translator SHOULD forward RTP
   No-Op payload packets normally; if the input stream is made up of RTP
   No-Op packets only, a corresponding RTP No-Op packet SHOULD be
   generated.  If the input stream consists of other packets than No-Op,
   then the No-Op packets SHOULD simply be discarded.  A unicast-to-
   multicast RTP translator SHOULD replicate RTP No-Op payload packets
   normally.







Andreasen, et al.       Expires October 29, 2007                [Page 5]


Internet-Draft          RTP No-Op Payload Format              April 2007


3.6.  Receiver Operation

   Upon receipt of an RTP packet with the No-Op payload format the
   receiver performs normal 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 media.

3.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
   [RFC4566].

   The default packetization interval for this payload type is 20ms but
   alternate values can be advertised in SDP using the ptime or maxptime
   attributes [RFC4566].


4.  Example SDP Offer/Answer

   Offer:

         v=0
         o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
         s=-
         c=IN IP4 host.atlanta.example.com
         t=0 0
         m=audio 49170 RTP/AVP 0 96
         a=rtpmap:0 PCMU/8000
         a=rtpmap:96 no-op/8000
         m=video 41372 RTP/AVP 31 96
         a=rtpmap:31 H261/90000
         a=rtpmap:96 no-op/90000

   Answer:

         v=0
         o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
         s=-
         c=IN IP4 host.biloxi.example.com
         t=0 0
         m=audio 59174 RTP/AVP 0 96
         a=rtpmap:0 PCMU/8000
         a=rtpmap:96 no-op/8000
         m=video 59170 RTP/AVP 32 96
         a=rtpmap:31 H261/90000
         a=rtpmap:96 no-op/90000




Andreasen, et al.       Expires October 29, 2007                [Page 6]


Internet-Draft          RTP No-Op Payload Format              April 2007


5.  Media Type Registration

   This section registers media types for audio/no-op, video/no-op, and
   text/no-op, per [RFC4855].

5.1.  audio/no-op

   Media type name: audio

   Subtype name: no-op

   Required parameters: none

   Optional parameters: none

   Encoding considerations: This media type is framed and binary; see
   Section 4.8 in [RFC4288].

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

   Interoperability considerations: none

   Published specification: This document.

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

   Additional information: none.

   Person and email address to contact for further information: Dan Wing
   <dwing@cisco.com>.

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing and is
   only defined for transfer via RTP [RFC3550].  Transfer within other
   framing protocols is not defined at this time.

   Author: Flemming Andreasen, David Oran, and Dan Wing

   Change controller: IETF Audio/Video Transport working group delegated
   from the IESG.







Andreasen, et al.       Expires October 29, 2007                [Page 7]


Internet-Draft          RTP No-Op Payload Format              April 2007


5.2.  video/no-op

   Media type name: video

   Subtype name: no-op

   Required parameters: none

   Optional parameters: none

   Encoding considerations: This media type is framed and binary; see
   Section 4.8 in [RFC4288].

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

   Interoperability considerations: none

   Published specification: This document.

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

   Additional information: none.

   Person and email address to contact for further information: Dan Wing
   <dwing@cisco.com>.

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing and is
   only defined for transfer via RTP [RFC3550].  Transfer within other
   framing protocols is not defined at this time.

   Author: Flemming Andreasen, David Oran, and Dan Wing

   Change controller: IETF Audio/Video Transport working group delegated
   from the IESG.

5.3.  text/no-op

   Media type name: audio

   Subtype name: no-op

   Required parameters: none




Andreasen, et al.       Expires October 29, 2007                [Page 8]


Internet-Draft          RTP No-Op Payload Format              April 2007


   Optional parameters: none

   Encoding considerations: This media type is framed; see Section 4.8
   in [RFC4288].

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

   Interoperability considerations: none

   Published specification: This document.

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

   Additional information: none.

   Person and email address to contact for further information: Dan Wing
   <dwing@cisco.com>.

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing and is
   only defined for transfer via RTP [RFC3550].  Transfer within other
   framing protocols is not defined at this time.

   Author: Flemming Andreasen, David Oran, and Dan Wing

   Change controller: IETF Audio/Video Transport working group delegated
   from the IESG.


6.  Security Considerations

   There are no additional security considerations for this new RTP
   payload format; the RTP security considerations from RTP [RFC3550]
   apply.


7.  IANA Considerations

   IANA is requested to make media type registrations as specified above
   in Section 5







Andreasen, et al.       Expires October 29, 2007                [Page 9]


Internet-Draft          RTP No-Op Payload Format              April 2007


8.  Acknowledgments

   The authors thank Bob Biskner and Rajesh Kumar for their
   contributions to this specification.


9.  References

9.1.  Normative References

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

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

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, February 2007.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

9.2.  Informational References

   [I-D.ietf-behave-rfc3489bis]
              Rosenberg, J., "Session Traversal Utilities for (NAT)
              (STUN)", draft-ietf-behave-rfc3489bis-06 (work in
              progress), March 2007.

   [RFC3389]  Zopf, R., "Real-time Transport Protocol (RTP) Payload for
              Comfort Noise (CN)", RFC 3389, September 2002.

   [RFC4040]  Kreuter, R., "RTP Payload Format for a 64 kbit/s
              Transparent Call", RFC 4040, April 2005.

   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, June 2005.

   [I-D.ietf-avt-rtp-and-rtcp-mux]
              Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port",
              draft-ietf-avt-rtp-and-rtcp-mux-04 (work in progress),
              March 2007.




Andreasen, et al.       Expires October 29, 2007               [Page 10]


Internet-Draft          RTP No-Op Payload Format              April 2007


   [G729B]    International Telecommunications Union, "G.729 Annex B",
              November 1999,
              <http://www.itu.int/ITU-T/publications/recs.html>.


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 October 29, 2007               [Page 11]


Internet-Draft          RTP No-Op Payload Format              April 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Andreasen, et al.       Expires October 29, 2007               [Page 12]