One document matched: draft-wing-avt-rtp-noop-01.txt
Differences from draft-wing-avt-rtp-noop-00.txt
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] | PAFTECH AB 2003-2026 | 2026-04-23 00:02:27 |