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]