[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03

Network Working Group                                      M. Westerlund
Internet-Draft                                                 B. Burman
Intended status: Standards Track                                Ericsson
Expires: April 24, 2014                                 October 21, 2013

 RTCP Source Description Item SRCNAME to Label Individual Media Sources


   This document defines a new Source Description (SDES) item called
   SRCNAME, which uniquely identifies a single media source, like a
   camera or a microphone.  It also enables identification of the
   encoding to support when multiple ones are produced.  That way anyone
   receiving the SDES information from a set of interlinked RTP sessions
   can determine which SSRCs are logically related to the same media
   source and encoding.  In addition the new SDES item is also defined
   for usage with both a header extension and with the SDP source
   specific media attribute ("a=ssrc").  Enabling an end-point to
   receive the SRCNAME with the relevant RTP packets, as well as RTCP,
   or learn the source bindings through signalling, ahead of receiving
   RTP and RTCP packets.

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 April 24, 2014.

Copyright Notice

   Copyright (c) 2013 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

Westerlund & Burman      Expires April 24, 2014                 [Page 1]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   (http://trustee.ietf.org/license-info) in effect on the date of
   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.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Solution . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  SRCNAME Format . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  SDES Item SRCNAME  . . . . . . . . . . . . . . . . . . . .  7
     4.3.  SRCNAME in SDP . . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  SRCNAME as RTP Header Extension  . . . . . . . . . . . . .  8
   5.  Usage with the Offer/Answer Model  . . . . . . . . . . . . . .  8
   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . .  9
   7.  Relation to Application Token  . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

Westerlund & Burman      Expires April 24, 2014                 [Page 2]

Internet-Draft              RTCP SDES SRCNAME               October 2013

1.  Introduction

   This specification defines a new RTP/RTCP [RFC3550] Source
   Description (SDES) item called Source Name (SRCNAME).  There exist
   different use cases, including simulcast and scalable encoding, where
   a sender transmit multiple RTP packet streams containing full or
   partial encodings of the same media source.  This include multiple
   independent encodings, where it is desirable to identify the
   different encodings.  These different packet streams needs to be
   correctly associated with media sources and encodings in an receiver
   so that they correctly use the packet streams.

   The proposed solution provides the RTP packet streams (SSRCs) with
   identities for both the media source and the specific encoding.  The
   identification is done by creating a RTCP SDES item, SRCNAME, by
   combing a media source identifier and an encoding identifier
   separated by a full stop (".").  The SRCNAME can be sent periodically
   in RTCP SDES packets to enable joiners to receive the information
   within some time period from when they join.  The SRCNAME is also
   proposed to be sent in an RTP header extension for SDES items
   [I-D.westerlund-avtext-sdes-hdr-ext] when it is desirable to speed up
   reception.  For example by transmitting the SRCNAME in the first N
   RTP packets when a new SSRC joins an RTP session.  Finally the
   SRCNAME can be associated with the SSRC in signalling, and source
   specific attribute is provided for this purpose.

2.  Definitions

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.2.  Terminology

   This document uses terminology defined in "A Taxonomy of Grouping
   Semantics and Mechanisms for Real-Time Transport Protocol (RTP)
   Sources" [I-D.lennox-raiarea-rtp-grouping-taxonomy] .  In particular
   the following definitions:

   o  Media Source

   o  Packet Stream

   o  Media Encoder

Westerlund & Burman      Expires April 24, 2014                 [Page 3]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   o  Encoded Stream

   o  Dependent Stream

   o  Participant

   o  End point

3.  Motivation

   In RTP Applications where an end-point has more than one Media Source
   in a particular RTP session there can exist need to provide these
   media sources with an identifier.  One reason is to be able to
   explicitly track it across any SSRC collisions with resulting SSRC
   changes.  Another reason is when there exist multiple RTP Packet
   Streams (SSRC) associated with that particular media source.
   Especially in RTP sessions where multiple media sources are
   simultaneously transmitted.  This document focus on the cases that
   results in multiple packet streams due to the encoding process.

   Simulcast [I-D.westerlund-avtcore-rtp-simulcast] as referred to in
   this document is the process when communication participant provides
   a media source in multiple encodings using multiple media encoders
   with different configurations.  These different encoded streams are
   then simultaneously transmitted using RTP to a receiver or a group of
   receivers.  The receiver(s) need two things; First to determine which
   of the received packet streams (SSRCs) carries which media source,
   and thus determining the different media sources and secondly what
   alternative representations of each media source that exist.  This
   can be accomplished using an identifier to refer to a particular
   encoding of a media source.

   Scalable encoding is performed by some few media encoders, with the
   prime example being H.264 Scalable Video Codec [RFC6190].  A scalable
   media codec produces one or more base layers, i.e. an encoded stream,
   and additionally one or more enhancement layers that are dependent on
   the base layer as well as selected other enhancement layers, these
   called dependent streams.  The encoded and dependent streams can be
   sent using multiple RTP packet streams, called multi-stream
   transmission (MST).  Thus explicit information are required for which
   media source a particular packet stream (SSRC) are containing,
   independent if it is the encoded or dependent stream.  In cases where
   one uses multiple base layers, the encoding identifier can be used to
   provide RTP/RTCP level identification of the sub-groups of packet
   streams that form an independent dependency tree.  The detailed
   dependency information between the encoded streams and dependent
   streams are present in meta data information objects (SEI messages)

Westerlund & Burman      Expires April 24, 2014                 [Page 4]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   that are included inside the RTP payloads for SVC [RFC6190].

   By providing media source and encoding identity information on RTP
   and RTCP level we enable or improve usages that prior has been
   impractical or sub-optimal:

   a.  A multi-party sessions where the media sources dynamically join
       and leave and the central media node is source projection mixer.
       A large conference with some participant churn, in this case to
       rely solely on a signalling based solution can be problematic, as
       each signalling session between the conference and all the
       participants needs to be updated, for example using SIP, each
       time a participant joins or leaves.  Thus enabling RTP/RTCP level
       information enables the joining participant's flows to be
       explicitly indicated as new media sources and alternative
       representations on RTP/RTCP level and thus correctly handled.

   b.  Multicast or broadcast situations where session configuration
       information is provided ahead of the session, and the exact set
       of media sources and their identifies can't be determined and
       assigned ahead of time.

   c.  To optimize the away the need for buffering or holding
       transmission in centralized mixer cases when there is some delay
       on the signalling channel.  When a media source is added and the
       information is provided using signalling only, then a receiver
       that hasn't gotten the signalling yet, needs to either buffer or
       discard received media until the signalling arrives,
       alternatively, the sender needs to hold the transmission until
       the receiver have confirmed reception of signalling.

   d.  By providing this information in the RTP/RTCP also enables third
       party monitoring of the RTP/RTCP streams to work better as the
       stream relations are made clear.

   It is important to note that a particular RTP packet stream's role in
   a communication application can be quite independent to which media
   source and the particular encoding the packet stream is.  Although
   the media source and encoding is sufficient information in some use
   cases, there are other cases where additional information about the
   current role of packet stream or set of streams are required.
   Further discussion of this in Section 7.

   SRCNAME extends and complement the existing solutions using SDP Media
   Description grouping [RFC5888], or SSRC grouping within a Media
   Description in SDP [RFC5576] or implicit or heuristic based mapping
   of packet streams between or within RTP sessions.  SRCNAME enables
   explicit identity information at RTP/RTCP level in a form that are

Westerlund & Burman      Expires April 24, 2014                 [Page 5]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   unique across the whole communication session, usable to create
   relationships on RTP/RTCP level independent if one or more RTP
   session is used, independent on how the packet streams are
   distributed over those RTP sessions and how many media sources an
   end-point have.

4.  Solution

   This section defines the SRCNAME identifier format and its usage as
   RTCP SDES item [RFC3550], registers it as an SDES item possible to
   use in the RTP header extension for SDES items
   [I-D.westerlund-avtext-sdes-hdr-ext], and in a source specific SDP
   attribute [RFC5576] as well.

4.1.  SRCNAME Format

   The SRCNAME MUST fulfill the requirements Section 6.5 in RTP
   [RFC3550] puts on SDES item values in general.  These requirements is
   that it is a UTF-8 [RFC3629] text string that have a maximum length
   of 255 bytes.

   In addition, there are format restrictions to accommodate the
   separation of the Media Source ID and the encoding ID part, as
   described by the following ABNF [RFC5234]:

   media-source-id = 1*(%x01-09 / %x0B-0C / %x0E-1F / %x21-2D / %x2F-FF)
   encoding-id     = media-source-id *(%x2E media-source-id)
       ; Same as RFC 4566 "byte-string"
       ; except for space and the "." separator

   srcname-content = media-source %x2E encoding-id

                       Figure 1: SRCNAME Format ABNF

   Note, the format do allow multiple "." separators, but only as part
   of the encoding ID.

   The media source identifier is identifying a media source (as defined
   by section 2.1.4 of [I-D.lennox-raiarea-rtp-grouping-taxonomy]).
   Each media source ID MUST be unique when combined with the CNAME.
   Note that if one intended to byte compare the combination of CNAME
   and media-source-id then one need to pad the CNAME to full 255 bytes
   with a common pattern prior to concatenation and comparison.

   The encoding-id identifies a particular media encoder (Section 2.1.6
   in [I-D.lennox-raiarea-rtp-grouping-taxonomy]) and its set of

Westerlund & Burman      Expires April 24, 2014                 [Page 6]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   produced encoded or dependent streams (as defined per section 2.1.7
   and 2.1.8 in [I-D.lennox-raiarea-rtp-grouping-taxonomy]
   respectively).  The encoding-id MUST be unique in the context of the
   CNAME and the media source ID.

   By require uniqueness scoped by CNAME we simplify the creation of
   unique identifiers and reduce the overhead for the inclusion of
   SRCNAME.  As the CNAME defines the scope of a single synchronization
   context, commonly a single host will be responsible for assigning
   media source and encoding ID to media sources and their encodings.  A
   common case will be for having a single character media source ID
   followed by stop and then another single character encoding ID, e.g.


   Distributing the SRCNAME using a RTCP Source Descriptions (SDES) item
   are a method that should work with all RTP topologies (assuming that
   any intermediary node is supporting this item) and existing RTP
   extensions.  Thus, a new SDES item called SRCNAME are defined.  That
   way, anyone receiving the SDES information from a set of interlinked
   RTP sessions or SSRCs in a single session can determine the SRCNAME
   associated with each SSRC.

   The SDES SRCNAME item follows the same format as the other SDES items
   defined in RTP [RFC3550]:

    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
   | SRCNAME=TBA1  |     length    | source name                 ...

                       Figure 2: SDES SRCNAME Format

   The source name field MUST follow the above (Section 4.1) srcname-
   content definition.

   When using the SRCNAME SDES item, it is of equally importance with
   CNAME.  Thus, SRCNAME is RECOMMENDED to be included in all full
   compound RTCP packets being sent.  It MAY also be included in non-
   compound packets in cases where the implementation believes that
   there might be new receivers needing the information.

4.3.  SRCNAME in SDP

   "Source-Specific Media Attributes in the Session Description Protocol
   (SDP)" [RFC5576] defines a way of declaring attributes for SSRC in

Westerlund & Burman      Expires April 24, 2014                 [Page 7]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   each RTP session in SDP.  With a new SDES item, it is possible to use
   this framework to define how SRCNAME can also be provided in the SDP
   for each SSRC in each RTP session, thus enabling an end-point to
   declare and learn the source bindings ahead of receiving RTP/RTCP

   Hence, we define a new SDP source attribute called srcname with the
   following structure:

   a=ssrc:<ssrc-id> srcname:<srcname>

   The srcname value MUST be identical to the SRCNAME value the media
   sender will send in the SDES SRCNAME item in the SDES RTCP packets.

   Formal ABNF syntax [RFC5234] for the "srcname" attribute:

   srcname-attr = "srcname:" srcname

   srcname = srcname-content

   attribute =/ srcname-attr
      ; The definition of "attribute" is in RFC 4566.

                     Figure 3: SRCNAME Attribute ABNF

   When used in SDP, srcname-content MUST use ISO 10646 in UTF-8
   encoding, and MUST be independent of any "a=charset".

4.4.  SRCNAME as RTP Header Extension

   In cases when timely deliver of the SRCNAME is required, for example
   when adding a new SSRC to an RTP session, or when new receiver joins
   a multiparty RTP session, then the SRCNAME can be included in the RTP
   header extension for SDES items [I-D.westerlund-avtext-sdes-hdr-ext].

   The RTP header extension for SDES items
   [I-D.westerlund-avtext-sdes-hdr-ext] is functioning for any SDES
   item, but do require new SDES items to register its URN identifier.
   This is done below in the IANA section (Section 8).

5.  Usage with the Offer/Answer Model

   The SDP offer/answer procedures for a=ssrc are specified in Source-
   Specific Media Attributes in the Session Description Protocol (SDP)
   [RFC5576].  The SDP offer/answer procedures for a=exthdr are
   specified in A General Mechanism for RTP Header Extensions [RFC5285].

Westerlund & Burman      Expires April 24, 2014                 [Page 8]

Internet-Draft              RTCP SDES SRCNAME               October 2013

6.  Backward Compatibility

   Clients not supporting SRCNAME will not have the possibility to bind
   different streams to a specific media source, since they will not
   understand the SRCNAME SDES item or the RTP header extension.
   However, sending SRCNAME SDES items to a client not supporting it
   should not impose any problems since all clients should be prepared
   that new SDES items may be specified according to RTP [RFC3550].

   According to the definition of SDP attributes in SDP: Session
   Description Protocol [RFC4566], if an attribute is received that is
   not understood, it MUST be ignored by the receiver.  So a receiver
   not supporting the a=ssrc attribute will simply ignore it.

   Source-Specific Media Attributes in the Session Description Protocol
   (SDP) [RFC5576] defines rules of how new source attributes should be
   registered, which means that a receiver supporting RFC 5576 should be
   prepared that new source attributes may be defined.  This means that
   a user supporting some of the source attributes should not have any
   problems when the user receives an SDP with unknown source

   RTP header extension will only be used when successfully negotiated
   in SDP, which requires support in both sender and receiver.

7.  Relation to Application Token

   There exists a proposal for an application token SDES item
   [I-D.even-mmusic-application-token], who's purpose is to map SSRCs to
   application purposes or usages of the RTP packet stream.  In this
   section the similarities and differences are discussed to arrive at
   the conclusion that for a number of cases both will be required to
   enable powerful applications.

   The APPID is flexible in that it allows applications or specific
   usage of RTP to define how they map the APPID tokens to particular
   purpose or usages of the streams.  This is clearly intended to
   provide flexibility.  For example one APPID tokens can have meanings
   such as Presentation stream, main talker, video thumbnail number 3,
   FEC stream for Audio etc.  Such roles can be transient in their
   behavior.  For example main talker is a role that moves around in a
   multiparty communication session based on who is the current speaker,
   based on voice activity, or a conference management interface.  Thus,
   the APPID token for this role will be moved between different SSRCs.
   This is in strong contrast with SRCNAME which identifies a particular
   media source and encoding.  That is not expected to move around,
   other than in cases of SSRC collisions, when they enable tracking

Westerlund & Burman      Expires April 24, 2014                 [Page 9]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   across this event.  RTP Mixers that perform mixes or switching
   between input sources, are them selves having conceptual media
   sources, which will have stable identities.

   A case that makes it clear that SRCNAME identification may benefit
   from having additional role tokens is the case of having a source
   projection mixer using simulcast from clients to mixers.  From the
   perspective of a receiver, there will be multiple SSRCs visible for a
   particular media source, but the source projection mixer will select
   a sub-set of all potential streams to deliver.  A given sub-setting
   is to only deliver one representation of each media source to the
   receiver.  During a multiparty conference where a main speaker is
   shown larger at the receiver, and other participants are shown
   smaller, the mixer may due to congestion be forced to switch
   representation of the main speaker.  If the role would be strictly
   associated with the encoding representation then main speakers video
   may for example be reduced in display size.  If instead it is
   explicitly indicated using APPID the receiving application would
   continue to show the main speaker as a larger display area, despite
   the reduced quality to ensure the user continuous to understand that
   this is still the main talker.

   Where SRCNAME provides stable identification that a SSRC is
   associated with a media source and particular encoding of that media
   source, the APPID can function as a complement when needed to provide
   explicit indication of the current role and intended of application
   usage of a SSRC.

8.  IANA Considerations

   Following the guidelines in SDP [RFC4566], in The Session Description
   Protocol (SDP) Grouping Framework [RFC5888], and in RTP [RFC3550],
   the IANA is requested to register:

   1.  A new SDES item named SRCNAME, as defined in Section 4.2.  This
       item needs to be assigned an identifier TBA1.

   2.  A new SDP source attribute named srcname, as defined in
       Section 4.3.

   3.  New RTP header extension URN identifiers for SRCNAME, as defined
       in Section 4.4.

Westerlund & Burman      Expires April 24, 2014                [Page 10]

Internet-Draft              RTCP SDES SRCNAME               October 2013

9.  Security Considerations

   The SDES item or header extension SRCNAMEs being close to opaque
   identifiers could potentially carry additional meanings or function
   as overt channel.  If the SRCNAME would be permanent between
   sessions, they have the potential for compromising the users' privacy
   as they can be tracked between sessions.  See Guidelines for Choosing
   RTP Control Protocol (RTCP) Canonical Names (CNAMEs) [RFC7022] for
   more discussion.

   A third party modification of the srcname labels either in the RTCP
   SDES items, in the SDP a=ssrc attribute, or in the RTP header
   extension can cause service disruption.  By modifying labels the
   wrong streams could be associated, with potentially serious effects
   including media disruptions.  If streams that are to be associated
   aren't associated, then another type of failures occur.  To prevent
   modification, insertion or deletion of the srcname labels, the
   carrying channel needs to be protected by integrity protection and
   source authentication.  For RTCP and RTP header extension, various
   solutions exist, such as SRTP [RFC3711], DTLS [RFC6347], or IPsec
   [RFC4301].  For protecting the SDP, the signalling channel needs to
   provide protection.  For SIP S/MIME [RFC3261] are the ideal, and hop
   by hop TLS [RFC5246] provides at least some protection, although not
   perfect.  For SDPs retrieved using RTSP DESCRIBE [RFC2326], TLS would
   be the RECOMMENDED solution.

10.  References

10.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.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

Westerlund & Burman      Expires April 24, 2014                [Page 11]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   [RFC7022]  Begen, A., Perkins, C., Wing, D., and E. Rescorla,
              "Guidelines for Choosing RTP Control Protocol (RTCP)
              Canonical Names (CNAMEs)", RFC 7022, September 2013.

10.2.  Informative References

              Even, R., Lennox, J., and Q. Wu, "The Session Description
              Protocol (SDP) Application Token Attribute",
              draft-even-mmusic-application-token-01 (work in progress),
              September 2013.

              Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
              B. Burman, "A Taxonomy of Grouping Semantics and
              Mechanisms for Real-Time Transport Protocol (RTP)
              Sources", draft-lennox-raiarea-rtp-grouping-taxonomy (work
              in progress), October 2013.

              Westerlund, M. and B. Burman, "Using Simulcast in RTP
              sessions", draft-westerlund-avtcore-rtp-simulcast (work in
              progress), October 2013.

              Westerlund, M., Burman, B., and R. Even, "RTP Header
              Extension for RTCP Source Description Items",
              draft-westerlund-avtext-sdes-hdr-ext (work in progress),
              October 2013.

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

Westerlund & Burman      Expires April 24, 2014                [Page 12]

Internet-Draft              RTCP SDES SRCNAME               October 2013

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, July 2008.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

   [RFC6190]  Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
              "RTP Payload Format for Scalable Video Coding", RFC 6190,
              May 2011.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

Authors' Addresses

   Magnus Westerlund
   Farogatan 6
   SE-164 80 Kista

   Phone: +46 10 714 82 87
   Email: magnus.westerlund@ericsson.com

   Bo  Burman
   Farogatan 6
   SE-164 80 Kista

   Phone: +46 10 714 13 11
   Email: bo.burman@ericsson.com

Westerlund & Burman      Expires April 24, 2014                [Page 13]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/