Internet DRAFT - draft-alvestrand-sdp-header
draft-alvestrand-sdp-header
Network Working Group H. Alvestrand
Internet-Draft Alvestrand Data
Intended status: Experimental April 1, 2014
Expires: October 3, 2014
The SDP RTCP Extension
draft-alvestrand-sdp-header-00
Abstract
This document specifies an RTCP extension that allows SDP information
to be carried over an RTP session. This extension obivates the need
for a separate negotiation channel, thereby avoiding the risk of
desynchronization between the SDP session description and the RTP
session state.
Requirements Language
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 October 3, 2014.
Copyright Notice
Copyright (c) 2014 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
Alvestrand Expires October 3, 2014 [Page 1]
Internet-Draft SDP Extension April 2014
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transmission Rules for The SDP RTCP Extension . . . . . . . . . 3
3. Packet format for the SDP RTP Extension . . . . . . . . . . . . 4
4. Packet size considerations . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Alvestrand Expires October 3, 2014 [Page 2]
Internet-Draft SDP Extension April 2014
1. Introduction
It has long been recognized as an issue that there's no universal
means of correlating the session description in an SDP exchange with
the RTP session that it describes while the session is being
negotiated. This document describes a means of correlation that will
always succeed, by placing the session description on the RTP
session.
2. Transmission Rules for The SDP RTCP Extension
The mechanism described here is a quite straightforward application
of the SDP offer/answer exchange from [RFC3264] : It embeds the SDP
offer and answer into an RTCP packet, which is sent to the other
party.
The rules of transmission for the offerer are as follows:
o The RTCP packet containing the SDP offer (the Offer Packet) MUST
be the first packet sent.
o The RTCP packet MUST be repeated at the minimum RTCP transmission
interval until the Answer Packet is received.
o No RTCP packet without an SDP offer can be sent until the Offer/
Answer exchange has been completed.
o Once the Answer Packet is received, the Offerer MUST send out an
RTCP packet without any SDP extension. This serves to tell the
Answerer that the Answer has been received.
o If the Offerer sees an RTCP Offer packet, indicating an offer
collision, it MUST draw a random number between 0 and 1. If the
result is 0, it will abandon its Offer and instead emit an Answer.
If the result is 1, it will continue sending its Offer. The
procedures for resolving the situation when both parties switch to
Answer mode are TBD.
The rules of transmission for the answerer are as follows:
o On reception of an Offer, the Answerer MUST send an Answer as soon
as it has determined that an answer is warranted.
o The answerer MUST repeat it answer at the maximum rate permitted
by the RTCP transmission interval.
Alvestrand Expires October 3, 2014 [Page 3]
Internet-Draft SDP Extension April 2014
o When an RTCP packet without an SDP extension is received, it MUST
stop sending the Answer.
3. Packet format for the SDP RTP Extension
The extension is allocated a new RTCP Control Packet Type, 212, with
the acronym APR - Application Parameter Renegotiation.
The first byte of the control packet has the values 1 or 2,
indicating either an Offer or an Answer. The first message to be
sent will therefore always have the identifier APR 1.
The values 0 and 3-255 are reserved, and MUST NOT be sent.
Application behaviour on reception is undefined.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=APR=212 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SDP code = 1 | SDP Offer |
.....
SDP Offer packet
The header of the APR packet is to be interpreted by analogy to the
SR packet.
The SDP Offer is represented in ASCII.
4. Packet size considerations
The maximum length of an RTCP packet payload is 2^16 32-bit words, or
262 Kbytes. This should be adequate for most SDP payload sizes.
However, if one desires to carry RTCP over UDP, the practical payload
size is limited by the UDP fragmentation mechanism, which tops out at
64 Kbytes. Again, this limit is not likely to be a problem in
practice.
Some networks have issues with UDP packets larger than the MTU.
While these networks are non-conformant, and should be expected to
improve their conformance, there may exist situations in which one is
limited to an MTU of 1500 bytes, which is clearly inadequate for a
Alvestrand Expires October 3, 2014 [Page 4]
Internet-Draft SDP Extension April 2014
number of common SDP scenarios.
Because of these situations, implementations of this extension MUST
implement the RTCP Advanced Compression Keybinding Toolkit [RACKT].
5. IANA Considerations
This document requests that IANA register a new RTCP packet format,
212.
6. Security Considerations
Due to the fact that RTCP packets are used to carry the SDP used to
set up a security association, keying for the RTCP session is a bit
difficult. It is therefore RECOMMENDED that after establishing a
security association, the SDP negotiation be repeated, in the same
manner as the "patch-up" exchange common to ICE, BUNDLE and several
other SDP mechanisms.
7. Acknowledgements
This document does not name the inspiring parties.
8. Normative References
[RACKT] Defined, TB., "RTCP Advanced Compression Keybinding
Toolkit", April 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
Author's Address
Harald Alvestrand
Alvestrand Data
Email: harald@alvestrand.no
Alvestrand Expires October 3, 2014 [Page 5]