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

Versions: 00 01 02 03

Network Working Group                                      M. Westerlund
Internet-Draft                                                 B. Burman
Intended status: Standards Track                             P. Sandgren
Expires: April 26, 2012                                         Ericsson
                                                        October 24, 2011


           RTCP SDES Item SRCNAME to Label Individual Sources
              draft-westerlund-avtext-rtcp-sdes-srcname-00

Abstract

   This document defines a new SDES item called SRCNAME which uniquely
   identifies a single media source, like a camera or a microphone.
   That way anyone receiving the SDES information from a set of
   interlinked RTP sessions can determine which SSRCs are related to the
   same source.  It can equally be used to label SSRC multiplexed
   related streams, such as FEC or Retransmission streams related to the
   original source stream in the same session.  In addition the new SDES
   item is also defined for usage with the SDP source specific media
   attribute ("a=ssrc") enabling an end-point to declare and learn the
   source bindings ahead of receiving RTP/RTCP packets through
   signalling.

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 26, 2012.

Copyright Notice

   Copyright (c) 2011 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, et al.       Expires April 26, 2012                 [Page 1]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   (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.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  5
   3.  SDES Item SRCNAME  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  SRCNAME in SDP . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Simulcast  . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  SVC with multi-session transmission  . . . . . . . . . . .  8
     5.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Forward Error Correction . . . . . . . . . . . . . . . . . 10
   6.  Usage with the Offer/Answer Model  . . . . . . . . . . . . . . 11
   7.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14























Westerlund, et al.       Expires April 26, 2012                 [Page 2]


Internet-Draft              RTCP SDES SRCNAME               October 2011


1.  Introduction

   RTP has always been a protocol that supports multiple participants
   each sending their own media streams in RTP sessions.  Previously
   many implementations have aimed only at point to point voice over IP
   with a single source in each end-point.  Even client implementations
   aimed at video conferences have often been built with the assumption
   around central mixers that only deliver a single media stream per
   media type.  However, more advanced client implementations may
   transmit multiple streams in the same RTP session and there may be
   tight relations between different streams and their SSRCs.  For
   example, a client with several cameras that uses simulcast to send
   streams with different encodings of the video from each camera have
   the need of conveying the relation of the streams to the receiver.  A
   similar example is a client with several cameras that uses SVC multi-
   session transmission [RFC6190] and also here the receiver needs to
   know which streams relate to which video source.  Other examples of
   tight relations are a retransmission stream and its original stream
   as well as the case of forward error correction (FEC) where a client
   can send source streams and associated repair streams.

   CNAME is not sufficient to express this relation although that is
   commonly inferred from end-points that have only one media stream per
   media type.  The primary use of CNAME in multi-source usages is
   instead to indicate which end-point and what synchronization context
   a particular media stream relates to and that usually means that all
   streams sent from a client have the same CNAME.  We are neither
   relying on using the same SSRC for all streams related to a
   particular media source as it is not robust against SSRC collision
   and forces potentially cascading SSRC changes between sessions.
   Also, using the same SSRC is not possible when SSRC-multiplexing is
   used.

   A common solution to convey the relation between streams is to use
   SDP attributes.  Session-multiplexed streams can be associated with
   an attribute that groups different RTP sessions and SSRC-multiplexed
   streams can be grouped at the media level for each RTP session.  For
   example, in Forward Error Correction Grouping Semantics in the
   Session Description Protocol [RFC5956] an SDP media level attribute
   called "ssrc-group:FEC-FR" is used for grouping FEC associations when
   the different streams from a source are SSRC-multiplexed in the same
   RTP session.  Using SDP attributes may work fine in the case when the
   receivers of the streams also get an SDP describing the bindings of
   all the streams, but that is not always the case.  One such example
   is a conference session where clients are communicating with each
   other via an RTP Translator.  The RTP Translator forwards all RTP and
   RTCP traffic from a client to all other clients and the clients can
   be prepared to receive any number of streams of certain specified



Westerlund, et al.       Expires April 26, 2012                 [Page 3]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   media.  When a new client joins the session the other clients may not
   be notified with a SIP Update including a new SDP, instead the
   clients will detect the new client's streams via RTP and RTCP.  In
   this case there is no way for a client to identify if certain streams
   are related to each other since that information only was included in
   the SDP.

   RTP Retransmission Payload Format [RFC4588] describes a solution for
   finding the association between original streams and retransmission
   streams when SSRC-multiplexing is used.  The association can be
   resolved when the receiver receives a retransmission packet matching
   a retransmission request sent earlier.  However, the RFC continues
   with describing that this mechanism might fail if there are two
   outstanding requests for the same packet sequence number in two
   different original streams of a session.  Therefore, to avoid
   ambiguity in unicast a receiver MUST NOT have two outstanding
   requests for the same packet sequence number in two different
   original streams before the association is resolved.  For multicast,
   however, this ambiguity cannot be avoided and SSRC-multiplexing of
   original and retransmission streams is therefore prohibited in
   multicast.  By defining a solution for one to one mapping between an
   original stream and any supporting streams this issue can be avoided
   in the future.  Note: This document does not update RFC 4588 to use
   this solution, but it may be done in the future.

   To enable an RTP session participant to determine the close relation
   of different streams without the above mentioned problems, a new
   method for identifying such sources is needed.  RTP [RFC3550] defines
   the Source Description RTCP Packet (SDES), which contains one or more
   chunks, each of which is composed of SDES items describing the SSRC
   identified in that chunk.  None of the present SDES items is,
   however, suitable for uniquely identifying a media source.

   Therefore we propose that one defines a new SDES item called the
   SRCNAME which with a unique label identifies a single media source,
   like a camera or a microphone.  The source may also be a particular
   media mix or conceptual stream, such as the "most active speaker"
   output by a RTP mixer performing stream switching.  That way anyone
   receiving the SDES information from a set of interlinked RTP sessions
   or multiple SSRCs in the same session can determine which SSRCs are
   the same source.  Connecting streams with SRCNAME can be done
   irrespective of which multiplexing type is used and it solves the
   problems with the current solutions described above.

   It is, however, possible that a receiver will receive the RTP streams
   before receiving SDES packets with all SRCNAME items and that would
   mean that the receiver cannot make the connections between SSRCs and
   SRCNAMEs when starting to receive the media.  "Source-Specific Media



Westerlund, et al.       Expires April 26, 2012                 [Page 4]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   Attributes in the Session Description Protocol (SDP)" [RFC5576]
   defines a way of declaring different attributes for SSRCs in each
   session in SDP and if a new source attribute is added to this
   framework it would be suitable for conveying the connections between
   SSRCs and SRCNAMEs before the media communication starts.  Thus, in
   addition to the new SDES item we also define a new SDP source-
   specific media attribute called srcname, which enables an end-point
   to declare and learn the source bindings ahead of receiving RTP/RTCP
   packets.  Of course, this new SDP source attribute will not be useful
   for the case described above when clients did not get updates with
   new client's stream bindings, but it will be useful in most other
   cases.


2.  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].


3.  SDES Item SRCNAME

   Source Descriptions are a method that should work with all RTP
   topologies (assuming that any intermediary node is supporting this
   item) and existing RTP extensions.  Thus we propose that one defines
   a new SDES item called the SRCNAME which with a unique identifier
   identifies a single media source, like a camera, a microphone, a
   particular media mix, or conceptual stream.  That way anyone
   receiving the SDES information from a set of interlinked RTP sessions
   or SSRCs in a single session can determine which SSRCs are related to
   the same source.

   The SRCNAME is RECOMMENDED to be per communication session unique
   random identifiers generated according to "Guidelines for Choosing
   RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222] with
   the addition that a local counter enumerating the sources on the host
   also is concatenated to the key in step 4 prior to calculating the
   hash.  The SRCNAME included in an RTCP packet 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] string
   that have a maximum length of 255 bytes.

   This SRCNAME's relation to CNAME is the following.  CNAME represents
   an end-point and a synchronization context.  If the different sources
   identified by SRCNAMEs should be played out synchronized when
   receiving them in a multi-stream context, then the sources need to be
   in the same synchronization context.  Thus in all cases, all SSRCs



Westerlund, et al.       Expires April 26, 2012                 [Page 5]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   with the same SRCNAME will have the same CNAME.  A given CNAME may
   contain multiple sets of sources using different SRCNAMEs.

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

   When using the SRCNAME SDES item it is equally important to CNAME,
   thus it 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.  SRCNAME in SDP

   "Source-Specific Media Attributes in the Session Description Protocol
   (SDP)" [RFC5576] defines a way of declaring attributes for SSRC in
   each session in SDP.  With a new SDES item, one can use this
   framework to define how also the SRCNAME can 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
   packets.

   Hence, we propose 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.

   FormalABNF syntax [RFC5234] for the "srcname" attribute:
   srcname-attr = "srcname:" srcname

   ssrcname = byte-string
      ; The definition of "byte-string" is in RFC 4566.

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








Westerlund, et al.       Expires April 26, 2012                 [Page 6]


Internet-Draft              RTCP SDES SRCNAME               October 2011


5.  Examples

   This section shows SDP examples of declaring the SRCNAME in SDP.
   Only the relevant parts of the SDP are shown to improve readability.
   Please note that the below examples are all hypothetical as no
   decision has yet been to use the SRCNAME mechanism with the
   respective example.

5.1.  Simulcast

   In this use case the end-point is a client with a single audio source
   and two video sources and it uses simulcast for sending different
   encodings of the same video source.  This example is based on Using
   Simulcast in RTP sessions [I-D.westerlund-avtcore-rtp-simulcast].
   The following SDP describes this.
   s=Simulcast enabled client
   m=audio 49200 RTP/AVP 96
   a=rtpmap:96 G719/48000/2
   a=ssrc:521923924 cname:alice@foo.example.com
   a=ssrc:521923924 srcname:2b:45:c7:12:83:e6
   a=mid:1
   m=video 49300 RTP/AVP 96
   a=rtpmap:96 H264/90000
   a=fmtp:96 profile-level-id=42c01e
   a=imageattr:* send [x=640,y=360] recv [x=640,y=360] [x=320,y=180]
   a=ssrc:192392452 cname:alice@foo.example.com
   a=ssrc:192392452 srcname:a3:d3:4b:f1:22:12
   a=ssrc:834753488 cname:alice@foo.example.com
   a=ssrc:834753488 srcname:7a:39:a9:3e:28:f7
   a=mid:2
   a=content:main
   m=video 49400 RTP/AVP 96
   a=rtpmap:96 H264/90000
   a=fmtp:96 profile-level-id=42c00d
   a=imageattr:96 send [x=320,y=180]
   a=ssrc:239245219 cname:alice@foo.example.com
   a=ssrc:239245219 srcname:a3:d3:4b:f1:22:12
   a=ssrc:734623563 cname:alice@foo.example.com
   a=ssrc:734623563 srcname:7a:39:a9:3e:28:f7
   a=mid:3
   a=sendonly

   The audio session is proposing to use one stereo stream of G.719 and
   the video sessions are proposing to send two different encodings of
   each video source, one with the resolution 640x360 and one with
   320x180.  The end-point also declares the SSRCs it intends to use
   with bindings to CNAME and SRCNAME, enabling the receiver of the SDP
   to bind together the video streams that originates from the same



Westerlund, et al.       Expires April 26, 2012                 [Page 7]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   video camera.

   The use of the srcname attribute in the SDP is optional and the
   information can be retrieved from RTCP reporting, but it will then
   not be possible to correctly relate the video sources until the first
   RTCP report is received.

5.2.  SVC with multi-session transmission

   Here an example is shown of a client that uses SVC with multi-session
   transmission as described in RTP Payload Format for Scalable Video
   Coding [RFC6190].  RTP Payload Format for Scalable Video Coding
   [RFC6190] only describes examples for a client with one video source
   and the decoder dependencies of the different sessions are grouped
   using the Session grouping DDP attribute as defined in Signaling
   Media Decoding Dependency in the Session Description Protocol (SDP)
   [RFC5583] and implicitly CNAME.

   However, if a client has two video sources and wishes to use multi-
   session transmission and send streams from both sources in each
   session an additional grouping mechanism is needed to group the
   different streams in the different sessions.  SRCNAME is suitable for
   this and here we show an example where the DDP attribute groups the
   different sessions and the SRCNAME is used to relate the different
   SSRCs in each RTP session to one of the two video sources.


























Westerlund, et al.       Expires April 26, 2012                 [Page 8]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   s=SVC MST client
   a=group:DDP L1 L2 L3
   m=video 20000 RTP/AVP 96
   a=rtpmap:96 H264/90000
   a=fmtp:96 profile-level-id=4de00a; packetization-mode=1;
    mst-mode=NI-TC; sprop-parameter-sets={sps0},{pps0};
   a=ssrc:743947584 cname:bob@foo.example.com
   a=ssrc:743947584 srcname:7e:83:c1:82:e8:a6
   a=ssrc:283894947 cname:bob@foo.example.com
   a=ssrc:283894947 srcname:b3:8d:f1:18:c5:84
   a=mid:L1
   m=video 20002 RTP/AVP 97
   a=rtpmap:97 H264-SVC/90000
   a=fmtp:97 profile-level-id=53000c; packetization-mode=1;
    mst-mode=NI-T; sprop-parameter-sets={sps1},{pps1};
   a=ssrc:492784823 cname:bob@foo.example.com
   a=ssrc:492784823 srcname:7e:83:c1:82:e8:a6
   a=ssrc:892362397 cname:bob@foo.example.com
   a=ssrc:892362397 srcname:b3:8d:f1:18:c5:84
   a=mid:L2
   a=depend:97 lay L1:96
   m=video 20004 RTP/AVP 98
   a=rtpmap:98 H264-SVC/90000
   a=fmtp:98 profile-level-id=53001F; packetization-mode=1;
    mst-mode=NI-T; sprop-parameter-sets={sps2},{pps2};
   a=ssrc:184562894 cname:bob@foo.example.com
   a=ssrc:184562894 srcname:7e:83:c1:82:e8:a6
   a=ssrc:305605682 cname:bob@foo.example.com
   a=ssrc:305605682 srcname:b3:8d:f1:18:c5:84
   a=mid:L3
   a=depend:98 lay L1:96 L2:97


   Thus, the client declares that it will send two video streams in each
   RTP session and the receiver is then able to relate the streams in
   the different sessions by using the SRCNAME binding.  Without the
   SRCNAME binding it would not be possible for the receiver to know
   which streams belong to the same source.

5.3.  Retransmission

   This use case shows how SRCNAME can be used to connect retransmission
   streams to the original streams in the case of SSRC multiplexed RTP
   retransmission [RFC4588].  This is included to exemplify how RTP
   retransmission could be updated to provide explicit bindings between
   the source and the repair stream, but just an example and not a
   specification.




Westerlund, et al.       Expires April 26, 2012                 [Page 9]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   s=SSRC-multiplexed retransmission client
   m=audio 49200 RTP/AVP 96
   a=rtpmap:96 G719/48000/2
   a=ssrc:521923924 cname:carol@foo.example.com
   a=ssrc:521923924 srcname:88:3a:93:c1:3f:71
   a=mid:1
   m=video 49300 RTP/AVP 96 97
   a=rtpmap:96 H264/90000
   a=rtcp-fb:96 nack
   a=fmtp:96 profile-level-id=42c01e
   a=rtpmap:97 rtx/90000
   a=fmtp:97 apt=96;rtx-time=200
   a=ssrc:192392452 cname:carol@foo.example.com
   a=ssrc:192392452 srcname:7b:6e:23:8b:31:a8
   a=ssrc:834753488 cname:carol@foo.example.com
   a=ssrc:834753488 srcname:7b:6e:23:8b:31:a8
   a=ssrc:682394013 cname:carol@foo.example.com
   a=ssrc:682394013 srcname:c4:98:d9:1a:fc:58
   a=ssrc:284576129 cname:carol@foo.example.com
   a=ssrc:284576129 srcname:c4:98:d9:1a:fc:58
   a=mid:2

   The client proposes to send two original video streams in the video
   session and a retransmission stream for each one of them.  The
   retransmission streams are associated with the respective original
   stream by using the same SRCNAME and a receiver would then know which
   original stream a certain retransmission stream is associated with.
   This solves the ambiguity problem when SSRC-multiplexing is used for
   retransmission and it enables SSRC-multiplexing of original and
   retransmission streams to be used also in multicast sessions.

5.4.  Forward Error Correction

   Forward Error Correction Grouping Semantics in the Session
   Description Protocol [RFC5956] defines two SDP attributes for
   grouping the associated source and FEC-based repair streams.  One can
   be used for grouping different RTP sessions and the other can be used
   for grouping SSRCs in the same RTP session, i.e. when session-
   respective SSRC-multiplexing is used.  However, it may be
   advantageous to SSRC-multiplex the source streams in one RTP session
   and the repair streams in another since that gives a receiver the
   possibility to reject the repair session in case it does not support
   the proposed FEC.  In this case the above mentioned grouping
   attributes cannot be used to associate the repair streams with the
   respective source stream since grouping of SSRCs cannot be made
   across RTP sessions.  The following example shows how SRCNAME can be
   used for that.




Westerlund, et al.       Expires April 26, 2012                [Page 10]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   s=FEC client
   a=group:FEC-FR 1 2
   m=video 49200 RTP/AVP 100
   a=rtpmap:100 MP2T/90000
   a=ssrc:847612849 cname:dave@foo.example.com
   a=ssrc:847612849 srcname:45:a8:f4:19:b4:c3
   a=ssrc:558237845 cname:dave@foo.example.com
   a=ssrc:558237845 srcname:b8:58:29:c7:2f:9e
   a=mid:1
   m=application 49300 RTP/AVP 101
   a=rtpmap:101 1d-interleaved-parityfec/90000
   a=fmtp:101 L=5; D=10; repair-window=200000
   a=ssrc:389572053 cname:dave@foo.example.com
   a=ssrc:389572053 srcname:45:a8:f4:19:b4:c3
   a=ssrc:185729479 cname:dave@foo.example.com
   a=ssrc:185729479 srcname:b8:58:29:c7:2f:9e
   a=mid:2


   In this example the client proposes to send two video streams in one
   session and two repair streams in the other session.  The repair
   streams are associated with the respective video stream by using the
   same SRCNAME.  When receiving either this SDP or the SDES SRCNAME
   packets a receiver can make the connection between the source streams
   and the repair streams.  Even a client not receiving the SDP will be
   able to do the association if it has established one RTP session for
   receiving source streams and another for receiving repair streams.


6.  Usage with the Offer/Answer Model

   The SDP offer/answer procedures for the a=ssrc is specified in
   Source-Specific Media Attributes in the Session Description Protocol
   (SDP) [RFC5576].


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



Westerlund, et al.       Expires April 26, 2012                [Page 11]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   not supporting the 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 RFC5576 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
   attributes.


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 3.  This
       item needs to be assigned an identifier TBA1.

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


9.  Security Considerations

   The SDES SRCNAMEs being 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) [RFC6222] for more discussion.

   A third party modification of the srcname labels either in the RTCP
   SDES items or in the SDP a=ssrc attribute 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 various solutions exist, such as SRTP
   [RFC3711], DTLS [RFC4347], IPsec [RFC4301].  For protecting the SDP
   the signalling channel needs to provide protection.  For SIP S/MIME
   [RFC3261] are the ideal, and hop by hopTLS [RFC5246] provides at
   least some protection, although not perfect.  For SDP's retrieved
   using RTSP DESCRIBE [RFC2326] TLS would be the RECOMMENDED solution.




Westerlund, et al.       Expires April 26, 2012                [Page 12]


Internet-Draft              RTCP SDES SRCNAME               October 2011


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.

   [RFC6222]  Begen, A., Perkins, C., and D. Wing, "Guidelines for
              Choosing RTP Control Protocol (RTCP) Canonical Names
              (CNAMEs)", RFC 6222, April 2011.

10.2.  Informative References

   [I-D.westerlund-avtcore-rtp-simulcast]
              Westerlund, M., Burman, B., Lindqvist, M., and F. Jansson,
              "Using Simulcast in RTP sessions",
              draft-westerlund-avtcore-rtp-simulcast (work in progress),
              October 2011.

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




Westerlund, et al.       Expires April 26, 2012                [Page 13]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

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

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

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

   [RFC5583]  Schierl, T. and S. Wenger, "Signaling Media Decoding
              Dependency in the Session Description Protocol (SDP)",
              RFC 5583, July 2009.

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

   [RFC5956]  Begen, A., "Forward Error Correction Grouping Semantics in
              the Session Description Protocol", RFC 5956,
              September 2010.

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


Authors' Addresses

   Magnus Westerlund
   Ericsson
   Farogatan 6
   SE-164 80 Kista
   Sweden

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












Westerlund, et al.       Expires April 26, 2012                [Page 14]


Internet-Draft              RTCP SDES SRCNAME               October 2011


   Bo  Burman
   Ericsson
   Farogatan 6
   SE-164 80 Kista
   Sweden

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


   Patrik Sandgren
   Ericsson
   Farogatan 6
   SE-164 80 Kista
   Sweden

   Phone: +46 10 717 97 41
   Email: patrik.sandgren@ericsson.com

































Westerlund, et al.       Expires April 26, 2012                [Page 15]


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