One document matched: draft-ietf-avt-rtp-no-op-03.txt
Differences from draft-ietf-avt-rtp-no-op-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:16:29 |