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]