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

Versions: 00 01 02 03 draft-ietf-rtcweb-rtp-usage

Network Working Group                                         C. Perkins
Internet-Draft                                     University of Glasgow
Intended status: Informational                             M. Westerlund
Expires: September 8, 2011                                      Ericsson
                                                                  J. Ott
                                                        Aalto University
                                                           March 7, 2011

                      RTP Requirements for RTC-Web


   This document discusses usage of RTP in the context of RTC-WEB work.
   It discusses important factors of RTP to consider by other parts of
   the solution, it also discusses which RTP profile to support and
   which RTP extensions that should be supported.

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 September 8, 2011.

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

Perkins, et al.         Expires September 8, 2011               [Page 1]

Internet-Draft               RTP for RTC-Web                  March 2011

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements from RTP  . . . . . . . . . . . . . . . . . . . .  3
     2.1.  RTP Session Multiplexing . . . . . . . . . . . . . . . . .  4
     2.2.  Signalling for RTP sessions  . . . . . . . . . . . . . . .  6
     2.3.  (Lack of) Signalling for Payload Format Changes  . . . . .  7
   3.  RTP Profile  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  RTP and RTCP Guidelines  . . . . . . . . . . . . . . . . . . .  7
   5.  RTP Optimizations  . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  RTP and RTCP Multiplexing  . . . . . . . . . . . . . . . .  8
     5.2.  Reduced Size RTCP  . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . .  8
     5.4.  CNAME generation . . . . . . . . . . . . . . . . . . . . .  9
   6.  RTP Extensions . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  RTP Conferencing Extensions  . . . . . . . . . . . . . . .  9
       6.1.1.  RTCP Feedback Message: Full Intra Request  . . . . . . 10
       6.1.2.  RTCP Feedback Message: Picture Loss Indicator  . . . . 10
       6.1.3.  RTCP Feedback Message: Temporary Maximum Media
               Stream Bit Rate Request  . . . . . . . . . . . . . . . 10
     6.2.  RTP Header Extensions  . . . . . . . . . . . . . . . . . . 11
     6.3.  Rapid Synchronisation Extensions . . . . . . . . . . . . . 11
   7.  Improving RTP Transport Robustness . . . . . . . . . . . . . . 12
     7.1.  RTP Retransmission . . . . . . . . . . . . . . . . . . . . 12
     7.2.  Forward Error Correction . . . . . . . . . . . . . . . . . 12
   8.  RTP Rate Control and Media Adaptation  . . . . . . . . . . . . 12
   9.  RTP Performance Monitoring . . . . . . . . . . . . . . . . . . 13
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     13.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Perkins, et al.         Expires September 8, 2011               [Page 2]

Internet-Draft               RTP for RTC-Web                  March 2011

1.  Introduction

   This document discusses RTP in the context of RTC-WEB.  This include
   RTP's requirement on underlying transport, for example when it comes
   to provide multiplexing.  It discusses which RTP profile that should
   be supported and what RTP extensions that should be supported.  The
   importance of congestion control and media adaptation is also
   discussed.  This document is intended as a starting point for
   discussing RTP features in RTC-WEB.

   The work in the AVT WG has all been about providing building blocks
   and not specify who should use which building blocks.  Selection of
   building blocks and functionalities can really only be done in the
   context of some application(s).  RTC-WEB will greatly benefit in
   interoperability if a reasonable set of RTP functionalities and
   extensions are selected.  For RTC-WEB we have selected RTP extensions
   that are suitable for a number of applications that fits the context.
   Thus applications such as VoIP, audio and video conferencing, and on-
   demand multi-media streaming are considered.  Applications that rely
   on multicast transport has not been considered likely to be
   applicable to RTC-WEB, thus extensions related to multicast have been

   The document is structured into different topics.  For each topic one
   or several recommendations from the authors are done.  When it comes
   to extensions or need for implementation support we use three levels
   to indicate the importance for it to be included in an RTC-WEB
   specification.  We see it as likely that everything that is included
   is in fact mandated to be implemented.

   REQUIRED:  Absolutely needed functionality to make the solution work
      well.  Also functionality of low complexity that provide high
      value has also been categorized as required.

   RECOMMENDED:  Should be included as its brings significant benefit,
      but the solution can potentially work without it.

   OPTIONAL:  Something that is useful in some cases, but not always a

   When this documents discusses RTP it always include RTCP unless
   explicitly stated otherwise.  This as RTCP is a fundamental and
   integral part of the protocol.

2.  Requirements from RTP

   This section discusses some requirements RTP/RTCP [RFC3550] puts its

Perkins, et al.         Expires September 8, 2011               [Page 3]

Internet-Draft               RTP for RTC-Web                  March 2011

   underlying transport, the signalling etc.

2.1.  RTP Session Multiplexing

   RTP has three fundamental points of multiplexing.  The first one is
   the RTP session, which is used to separate media of different kind or
   purpose.  Such as Audio and Video, or the document camera and the
   speaker camera in video conference.  This multiplexing point does not
   have an identifier within the RTP protocol, instead it relies on the
   lower layer to separate the different RTP session.  Thus the most
   common RTP session separation is different UDP port numbers, but also
   IP address or other identifiers maybe used to achieve this
   separation.  The second multiplexing point is the SSRC that separates
   different sources of media within a single RTP session.  The third is
   the RTP Payload type, which identifies how the media from a
   particular source is encoded.

   These multiplexing points area fundamental part of the design of RTP
   and is discussed in Section 5.2 of [RFC3550].  From that list the
   ones that are directly related to the importance of the RTP session
   as concept are 4 and 5 (from RFC 3550):

   "4.  An RTP mixer would not be able to combine interleaved streams of
      incompatible media into one stream."

   "5.  Carrying multiple media in one RTP session precludes: the use of
      different network paths or network resource allocations if
      appropriate; reception of a subset of the media if desired, for
      example just audio if video would exceed the available bandwidth;
      and receiver implementations that use separate processes for the
      different media, whereas using separate RTP sessions permits
      either single- or multiple-process implementations."

   Point 4, has to do with media of different kind or purpose.  The
   processing that can happen in an RTP mixer, translator or in an end-
   point is dependent on the purpose and media type of the stream.  Thus
   there is an importance of separating such streams from each other.
   This could of course be achieved by other methods, like tagging SSRC
   values with their purpose, however there are reasons why this was not
   chosen.  First of all it is not the simple solution, as this require
   additional signalling, and possibly synchronization between session
   peers.  In addition there is the issue point 5 raises.

   Point 5 has to do with enabling quality of service or traffic
   engineering between the media flows in different RTP sessions.  By
   using different transport layer ports, QoS mechanism that are capable
   of operating on the 5-tuple (Source address, port, destination
   address, port, and protocol) can be used without modification on RTP.

Perkins, et al.         Expires September 8, 2011               [Page 4]

Internet-Draft               RTP for RTC-Web                  March 2011

   Due to these design principle implementors of various services or
   applications using RTP has commonly not violated this model.  If one
   choses to violate it today one fails to achieve interoperability with
   a number of existing services, applications and implementations.

   Lets assume one overloads multiple RTP sessions into one by tagging
   the SSRC to belong to different purposes.  If one would gateway that
   design into a legacy system, then there would be a significant issue
   with SSRC collision.  This as the legacy system would not know about
   the need to avoid using the same SSRC in the different RTP sessions.

   There are also various RTP mechanism that has the potential for
   issues if one don't have a clear separation of RTP sessions:

   Scalabilty:  RTP was built with media scalability in consideration.
      The simplest way of achieving separation between different
      scalability layers are placing them in different RTP sessions, and
      using the same SSRC and CNAME in each session to bind them
      together.  This is most commonly done in multicast, and not
      particular applicable to RTC-WEB, but gatewaying of such a session
      would then require more alterations and likely stateful

   RTP Retransmission in Session Multiplexing mode:  RTP Retransmission
      [RFC4588] does have a mode for session multiplexing.  This would
      not be the main mode used in RTC-WEB, but for interoperability and
      reduced cost in translation support for different RTP Sessions are

   Forward Error Correction:  The "An RTP Payload Format for Generic
      Forward Error Correction" [RFC2733] and its update [RFC5109] can
      only be used on media formats that produce RTP packets that are
      smaller than half the MTU if the FEC flow and media flow being
      protected are to be sent in the same RTP session, this is due to
      "RTP Payload for Redundant Audio Data" [RFC2198].  This is because
      the SSRC value of the original flow is recovered from the FEC
      packets SSRC field.  So for anything that desires to use these
      format with RTP payloads that are close to MTU needs to put the
      FEC data in a separate RTP session compared to the original

   RTCP behavior also becomes a factor in why overloading RTP sessions
   is problematic.  The extension mechanisms used in RTCP depends on the
   media streams.  For example the Extended RTCP report block for VoIP
   is of suitable for conversational audio, but clearly not useful for
   Video.  This has three impacts, either one get unusable reports if
   they are generated for streams where there are little purpose.  This
   is maybe less likely for the VoIP report, but for example the more

Perkins, et al.         Expires September 8, 2011               [Page 5]

Internet-Draft               RTP for RTC-Web                  March 2011

   detailed media agnostic reports it may occur.  It otherwise makes the
   implementation of RTCP more complex as the SSRC purpose tagging needs
   not only to be one the media side, but also on the RTCP reporting.
   Also the RTCP reporting interval and transmission scheduling will be

   As a conclusion not ensuring that RTP sessions are used for its
   intended purpose as a multiplexing point does violate the RTP design
   philosophy.  It prevents the usage of certain RTP extensions.  It
   will require additional extensions to function and will significantly
   increase the complexity of the implementation.  At the same time it
   will significantly reduce the interoperability with current

2.2.  Signalling for RTP sessions

   RTP is built with the assumption of an external to RTP/RTCP
   signalling channel to configure the RTP sessions and its functions.
   The basic configuration of an RTP session consists of the following

   RTP Profile:  The name of the RTP profile to be used in session.  The
      RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate
      on basic level, as can their secure variants RTP/SAVP [RFC3711]
      and RTP/SAVPF [RFC5124].  The secure variants of the profiles do
      not directly interoperate with the non-secure variants, due to the
      presence of additional header fields.

   Transport Information:  Source and destination address(s) and ports
      for RTP and RTCP must be signalled for each RTP session.  If RTP
      and RTCP multiplexing [RFC5761] is to be used, such that a single
      port is used for RTP and RTCP flows, this must be signalled.

   RTP Payload Types and Media formats:  The mapping between media type
      names (and hence the RTP payload formats to be used) and the RTP
      payload type numbers must be signalled.  Each media type may also
      have a number of media type parameters that must also be signalled
      to configure the codec and RTP payload format (the "a=fmtp:" line
      from SDP).

   Support for exchanging RTCP Bandwidth values to the end-points will
   be necessary, as described in "Session Description Protocol (SDP)
   Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth"
   [RFC3556], or something semantically equivalent.  This also ensures
   that the end-points have a common view of the RTCP bandwidth, this is
   important as too different view of the bandwidths may lead to failure
   to interoperate.

Perkins, et al.         Expires September 8, 2011               [Page 6]

Internet-Draft               RTP for RTC-Web                  March 2011

2.3.  (Lack of) Signalling for Payload Format Changes

   As discussed in Section 2.2, the mapping between media type name, and
   its associated RTP payload format, and the RTP payload type number to
   be used for that format must be signalled as part of the session
   setup.  An endpoint may signal support for multiple media formats, or
   multiple configurations of a single format, each using a different
   RTP payload type number.  If multiple formats are signalled by an
   endpoint, that endpoint must be prepared to receive data encoded in
   any of those formats at any time.  RTP does not require advance
   signalling for changes between formats that were signalled as part of
   the session setup.  This is necessary for rapid rate adaptation.

3.  RTP Profile

   The RTP profile REQUIRED to implement is "Extended Secure RTP Profile
   for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
   SAVPF)" [RFC5124].  Which will mean implicit support for AVPF
   [RFC4585], AVP [RFC3551] and SAVP [RFC3711].

   The AVPF part of SAVPF is required to get the improved RTCP timer
   model, that allows more flexible transmission of RTCP packets as
   response to events, rather than strictly according to bandwidth.
   This also saves RTCP bandwidth and will commonly only utilize the
   full amount when there is a lot of events to send feedback on.

   The S part of SAVPF is for support of SRTP.  This provides media
   encryption, integrity protection, replay protection and a limited
   form of source authentication.  It does not contain a specific keying
   mechanism.  So that and the set of security transforms will be
   required to be selected.  It is possible that a security mechanism
   operating on a lower layer than RTP can be used instead and that
   should be evaluated.  However, the reasons for the design of SRTP
   should be taken into consideration in that discussion.

4.  RTP and RTCP Guidelines

   RTP and RTCP are two flexible and extensible protocols that allow, on
   the one hand, choosing from a variety of building blocks and
   combining those to meet application needs, and on the other hand,
   create extensions where existing mechanisms are not sufficient: from
   new payload formats to RTP extension headers to additional RTCP
   control packets.

   Different informational documents provide guidelines to the use and
   particularly the extension of RTP and RTCP, including the following:

Perkins, et al.         Expires September 8, 2011               [Page 7]

Internet-Draft               RTP for RTC-Web                  March 2011

   Guidelines for Writers of RTP Payload Format Specifications [RFC2736]
   and Guidelines for Extending the RTP Control Protocol [RFC5968].

5.  RTP Optimizations

   This section discusses some optimizations that makes RTP/RTCP work
   better and more efficient and therefore are considered.

5.1.  RTP and RTCP Multiplexing

   Historically, RTP and RTCP have been run on separate UDP ports.  With
   the increased use of Network Address Port Translation (NAPT) this has
   become problematic, since maintaining multiple NAT bindings can be
   costly.  It also complicates firewall administration, since multiple
   ports must be opened to allow RTP traffic.  To reduce these costs and
   session setup times, support for multiplexing RTP data packets and
   RTCP control packets on a single port [RFC5761] is REQUIRED.

   Note that the use of RTP and RTCP multiplexed on a single port
   ensures that there is occasional traffic sent on that port, even if
   there is no active media traffic.  This may be useful to keep-alive
   NAT bindings.

5.2.  Reduced Size RTCP

   RTCP packets are usually sent as compound RTCP packets; and RFC 3550
   demands that those compound packets always start with an SR or RR
   packet.  However, especially when using frequent feedback messages,
   these general statistics are not needed in every packet and
   unnecessarily increase the mean RTCP packet size and thus limit the
   frequency at which RTCP packets can be sent within the RTCP bandwidth

   RFC5506 "Support for Reduced-Size Real-Time Transport Control
   Protocol (RTCP): Opportunities and Consequences" [RFC5506] specifies
   how to reduce the mean RTCP message and allow for more frequent
   feedback.  Frequent feedback, in turn, is essential to make real-time
   application quickly aware of changing network conditions and allow
   them to adapt their transmission and encoding behavior.

   Support for RFC5506 is REQUIRED.

5.3.  Symmetric RTP/RTCP

   RTP entities choose the RTP and RTCP transport addresses, i.e., IP
   addresses and port numbers, to receive packets on and bind their
   respective sockets to those.  When sending RTP packets, however, they

Perkins, et al.         Expires September 8, 2011               [Page 8]

Internet-Draft               RTP for RTC-Web                  March 2011

   may use a different IP address or port number for RTP, RTCP, or both;
   e.g., when using a different socket instance for sending and for
   receiving.  Symmetric RTP/RTCP requires that the IP address and port
   number for sending and receiving RTP/RTCP packets are identical.

   Using Symmetric RTP and RTCP [RFC4961] is REQURIED.

5.4.  CNAME generation

   The RTCP Canonical Name (CNAME) provides a persistent transport-level
   identifier for an RTP endpoint.  While the Synchronization Source
   (SSRC) identifier for an RTP endpoint may change if a collision is
   detected, or when the RTP application is restarted, it's RTCP CNAME
   is meant to stay unchanged, so that RTP endpoints can be uniquely
   identified and associated with their RTP media streams.  For proper
   functionality, RTCP CNAMEs should be unique within the participants
   of an RTP session.

   The RTP specification [RFC3550] includes guidelines for choosing a
   unique RTP CNAME, but these are not sufficient in the presence of NAT
   devices.  In addition, some may find long-term persistent identifiers
   problematic from a privacy viewpoint.  Accordingly, support for
   generating the RTP CNAME as specified in "Guidelines for Choosing RTP
   Control Protocol (RTCP) Canonical Names (CNAMEs)"
   [I-D.ietf-avt-rtp-cnames] is RECOMMENDED, since this addresses both

6.  RTP Extensions

   There are a number of RTP extensions that could be very useful in the
   RTC-WEB context.  One set is related to conferencing, others are more
   generic in nature.

6.1.  RTP Conferencing Extensions

   RTP is inherently defined for group communications, originally
   assuming the availability of IP multicast.  In today's practice,
   however, overlay-based conferencing dominates, typically using one or
   a few so-called conference bridges or servers to connect endpoints in
   a star or flat tree topology.  Quite diverse conferencing topologies
   can be created using the basic elements of RTP mixers and translators
   as defined in RFC 3550.

   An number of conferencing topologies are defined in [RFC5117] out of
   the which the following ones are the more common (and most likely in
   practice workable) ones:

Perkins, et al.         Expires September 8, 2011               [Page 9]

Internet-Draft               RTP for RTC-Web                  March 2011

   1) RTP Translator (Relay) with Only Unicast Paths (RFC 5117, section 

   2) RTP Mixer with Only Unicast Paths (RFC 5117, section 3.4)

   3) Point to Multipoint Using a Video Switching MCU (RFC 5117, section 

   4) Point to Multipoint Using Content Modifying MCUs (RFC 5117,
   section 3.6)

   RTP protocol extensions to be used with conferencing are included
   because they are important in the context of centralized
   conferencing, where one RTP Mixer (Conference Focus) receives a
   participants media streams and distribute them to the other
   participants.  These messages are defined in AVPF [RFC4585] or in
   "Codec Control Messages in the RTP Audio-Visual Profile with Feedback
   (AVPF)" [RFC5104].

6.1.1.  RTCP Feedback Message: Full Intra Request

   The Full Intra Request is defined in Section 3.51 and 4.3.1 of
   [RFC5104].  It is used to have the mixer request from the currently
   distributed session participants a new Intra picture.  This is used
   when switching between sources to ensure that the receivers can
   decode the video or other predicted media encoding with long
   prediction chains.  It is RECOMMENDED that this feedback message is

6.1.2.  RTCP Feedback Message: Picture Loss Indicator

   The Picture Loss Indicator is defined in Section 6.3.1 of [RFC4585].
   It is used by a receiver to tell the encoder that it lost the decoder
   context and would like to have it repaired somehow.  This is
   semantically different from the the Full Intra Request above.  It is
   RECOMMENDED that this feedback message is supported.

6.1.3.  RTCP Feedback Message: Temporary Maximum Media Stream Bit Rate

   This feedback message is defined in Section 3.5.4 and 4.2.1 in
   [RFC5104].  This message and its notification message is used by a
   media receiver, to inform the sending party that there is a current
   limitation on the amount of bandwidth available to this receiver.
   This can be for various reasons, and can for example be used by an
   RTP mixer to limit the media sender being forwarded by the mixer
   (without doing media transcoding) to fit the bottlenecks existing
   towards the other session participants.  It is RECOMMENDED that this

Perkins, et al.         Expires September 8, 2011              [Page 10]

Internet-Draft               RTP for RTC-Web                  March 2011

   feedback message is supported.

6.2.  RTP Header Extensions

   The RTP specification [RFC3550] provides a capability to extend the
   RTP header with in-band data, but the format and semantics of the
   extensions are poorly specified.  Accordingly, if header extensions
   are to be used, it is REQUIRED that they be formatted and signalled
   according to the general mechanism of RTP header extensions defined
   in [RFC5285].

   As noted in [RFC5285], the requirement from the RTP specification
   that header extensions are "designed so that the header extension may
   be ignored" [RFC3550] stands.  To be specific, header extensions must
   only be used for data that can safely be ignored by the recipient
   without affecting interoperability, and must not be used when the
   presence of the extension has changed the form or nature of the rest
   of the packet in a way that is not compatible with the way the stream
   is signaled (e.g., as defined by the payload type).  Valid examples
   might include metadata that is additional to the usual RTP

   The RTP rapid synchronisation header extension is recommended, as
   discussed in Section 6.3.

   Currently no other header extensions are recommended.  But we do
   include a list of the available ones for consideration below:

   Transmission Time offsets:  [RFC5450] defines a format for including
      an RTP timestamp offset of the actual transmission time of the RTP
      packet in relation to capture/display timestamp present in the RTP
      header.  This can be used to improve jitter determination and
      buffer management.

   Associating Time-Codes with RTP Streams:  [RFC5484] defines how to
      associate SMPTE times codes with the RTP streams.

   Audio Levels indications:  There is ongoing work to define RTP header
      extensions for providing audio levels both from a media sender to
      an mixer [I-D.ietf-avtext-client-to-mixer-audio-level], and from a
      mixer to a receiver[I-D.ietf-avtext-mixer-to-client-audio-level].

6.3.  Rapid Synchronisation Extensions

   Many RTP sessions require synchronisation between audio, video, and
   other content.  This synchronisation is performed by receivers, using
   information contained in RTCP SR packets, as described in the RTP
   specification [RFC3550].  This basic mechanism can be slow, however,

Perkins, et al.         Expires September 8, 2011              [Page 11]

Internet-Draft               RTP for RTC-Web                  March 2011

   so it is RECOMMENDED that the rapid RTP synchronisation extensions
   described in [RFC6051] be implemented.  The rapid synchronisation
   extensions use the general RTP header extension mechanism [RFC5285],
   which requires signalling, but are otherwise backwards compatible.

7.  Improving RTP Transport Robustness

   There are some tools that can robustify RTP flows against Packet loss
   and reduce the impact on media quality.  However they all add extra
   bits compared to a non-robustified stream.  These extra bits needs to
   be considered and the aggregate bit-rate needs to be rate controlled.
   Thus robustification might require a lower base encoding quality but
   has the potential to give that quality with fewer errors in it.

7.1.  RTP Retransmission

   Support for RTP retransmission as defined by "RTP Retransmission
   Payload Format" [RFC4588] is RECOMMENDED.

   The retransmission scheme in RTP allows flexible application of
   retransmissions.  Only selected missing packets can be requested by
   the receiver.  It also allows for the sender to prioritize between
   missing packets based on senders knowledge about their content.
   Compared to TCP, RTP retransmission also allows one to give up on a
   packet that despite retransmission(s) still has not been received
   within a time window.

7.2.  Forward Error Correction

   Support of some type of FEC scheme to combat packet loss is
   beneficial, but is application dependent and also claimed to be
   mostly encumbered.  For further discussion.

8.  RTP Rate Control and Media Adaptation

   It is REQUIRED to have an RTP Rate Control mechanism using Media
   adaptation to ensure that the generated RTP flows are network

   The biggest issue is that there are no standardized and ready to use
   mechanism that can simply be included in RTC-WEB.  Thus there will be
   need for the IETF to produce such a specification.  A potential
   starting point for defining a solution is "RTP with TCP Friendly Rate

Perkins, et al.         Expires September 8, 2011              [Page 12]

Internet-Draft               RTP for RTC-Web                  March 2011

9.  RTP Performance Monitoring

   RTCP does contains a basic set of RTP flow monitoring points like
   packet loss and jitter.  There exist a number of extensions that
   could be included in the set to be supported.  However, in most cases
   which RTP monitoring that is needed depends on the application, which
   makes it difficult to select which to include when the set of
   applications is very large.

10.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

11.  Security Considerations

   RTP and its various extensions each have their own security
   considerations.  These should be taken into account when considering
   the security properties of the complete suite.  We currently don't
   think this suite creates any additional security issues or
   properties.  The usage of SRTP will provide protection or mitigation
   against all the fundamental issues by offering confidentiality,
   integrity and partial source authentication.  We don't discuss the
   key-management aspect of SRTP in this document, that needs to be done
   taking the RTC-WEB communication model into account.

   In the context of RTC-WEB the actual security properties required
   from RTP are currently not fully understood.  Until security goals
   and requirements are specified it will be difficult to determine what
   security features in addition to SRTP and a suitable key-management,
   if any, that are needed.

12.  Acknowledgements

13.  References

13.1.  Normative References

              Begen, A., Perkins, C., and D. Wing, "Guidelines for
              Choosing RTP Control Protocol (RTCP) Canonical Names
              (CNAMEs)", draft-ietf-avt-rtp-cnames-05 (work in

Perkins, et al.         Expires September 8, 2011              [Page 13]

Internet-Draft               RTP for RTC-Web                  March 2011

              progress), January 2011.

              Lennox, J., Ivov, E., and E. Marocco, "A Real-Time
              Transport Protocol (RTP) Header Extension for Client-to-
              Mixer Audio Level Indication",
              draft-ietf-avtext-client-to-mixer-audio-level-00 (work in
              progress), February 2011.

              Ivov, E., Marocco, E., and J. Lennox, "A Real-Time
              Transport Protocol (RTP) Header Extension for Mixer-to-
              Client Audio Level Indication",
              draft-ietf-avtext-mixer-to-client-audio-level-00 (work in
              progress), February 2011.

   [RFC2733]  Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
              for Generic Forward Error Correction", RFC 2733,
              December 1999.

   [RFC2736]  Handley, M. and C. Perkins, "Guidelines for Writers of RTP
              Payload Format Specifications", BCP 36, RFC 2736,
              December 1999.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              July 2003.

   [RFC3556]  Casner, S., "Session Description Protocol (SDP) Bandwidth
              Modifiers for RTP Control Protocol (RTCP) Bandwidth",
              RFC 3556, July 2003.

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

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              July 2006.

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

Perkins, et al.         Expires September 8, 2011              [Page 14]

Internet-Draft               RTP for RTC-Web                  March 2011

   [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
              BCP 131, RFC 4961, July 2007.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, February 2008.

   [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
              January 2008.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, February 2008.

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

   [RFC5450]  Singer, D. and H. Desineni, "Transmission Time Offsets in
              RTP Streams", RFC 5450, March 2009.

   [RFC5484]  Singer, D., "Associating Time-Codes with RTP Streams",
              RFC 5484, March 2009.

   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, April 2009.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.

   [RFC5968]  Ott, J. and C. Perkins, "Guidelines for Extending the RTP
              Control Protocol (RTCP)", RFC 5968, September 2010.

   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
              Flows", RFC 6051, November 2010.

13.2.  Informative References

   [RFC2198]  Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
              Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
              Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
              September 1997.

              Gharai, L., "RTP with TCP Friendly Rate Control

Perkins, et al.         Expires September 8, 2011              [Page 15]

Internet-Draft               RTP for RTC-Web                  March 2011

              (draft-gharai-avtcore-rtp-tfrc-00)", March 2011.

Authors' Addresses

   Colin Perkins
   University of Glasgow
   School of Computing Science
   Glasgow  G12 8QQ
   United Kingdom

   Email: csp@csperkins.org

   Magnus Westerlund
   Farogatan 6
   SE-164 80 Kista

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

   Joerg Ott
   Aalto University
   School of Electrical Engineering
   Espoo  02150

   Email: jorg.ott@aalto.fi

Perkins, et al.         Expires September 8, 2011              [Page 16]

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