One document matched: draft-perkins-rtcweb-rtp-usage-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-perkins-rtcweb-rtp-usage-00"
     ipr="trust200902">
  <front>
    <title abbrev="RTP for RTC-Web">RTP Requirements for RTC-Web</title>

    <author fullname="Colin Perkins" initials="C. S." surname="Perkins">
      <organization>University of Glasgow</organization>

      <address>
        <postal>
          <street>School of Computing Science</street>

          <city>Glasgow</city>

          <code>G12 8QQ</code>

          <country>United Kingdom</country>
        </postal>

        <email>csp@csperkins.org</email>
      </address>
    </author>

    <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
      <organization>Ericsson</organization>

      <address>
        <postal>
          <street>Farogatan 6</street>

          <city>SE-164 80 Kista</city>

          <country>Sweden</country>
        </postal>

        <phone>+46 10 714 82 87</phone>

        <email>magnus.westerlund@ericsson.com</email>
      </address>
    </author>

    <author fullname="Joerg Ott" initials="J." surname="Ott">
      <organization>Aalto University</organization>

      <address>
        <postal>
          <street>School of Electrical Engineering</street>

          <city>Espoo</city>

          <code>02150</code>

          <country>Finland</country>
        </postal>

        <email>jorg.ott@aalto.fi</email>
      </address>
    </author>

    <date year="2011" />

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <!--Possible todos: Number each implementation requirement so that they can be directly referenced.-->

    <section title="Introduction">
      <t>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.</t>

      <t>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 excluded.</t>

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

      <t><list style="hanging">
          <t hangText="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.</t>

          <t hangText="RECOMMENDED:">Should be included as its brings
          significant benefit, but the solution can potentially work without
          it.</t>

          <t hangText="OPTIONAL:">Something that is useful in some cases, but
          not always a benefit.</t>
        </list>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.</t>
    </section>

    <section title="Requirements from RTP">
      <t>This section discusses some requirements <xref
      target="RFC3550">RTP/RTCP</xref> puts its underlying transport, the
      signalling etc.</t>

      <section title="RTP Session Multiplexing">
        <t>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.</t>

        <t>These multiplexing points area fundamental part of the design of
        RTP and is discussed in Section 5.2 of <xref target="RFC3550"></xref>.
        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):</t>

        <t><list style="hanging">
            <t hangText=""4.">An RTP mixer would not be able to combine
            interleaved streams of incompatible media into one stream."</t>

            <t hangText=""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."</t>
          </list>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.</t>

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

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

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

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

        <t><list style="hanging">
            <t hangText="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
            translation.</t>

            <t
            hangText="RTP Retransmission in Session Multiplexing mode:"><xref
            target="RFC4588">RTP Retransmission</xref> 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 required.</t>

            <t hangText="Forward Error Correction:">The <xref
            target="RFC2733">"An RTP Payload Format for Generic Forward Error
            Correction"</xref> and its update <xref target="RFC5109"></xref>
            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
            <xref target="RFC2198"> "RTP Payload for Redundant Audio
            Data"</xref>. 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 transmissions.</t>
          </list>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
        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
        affected.</t>

        <t>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
        implementations.</t>
      </section>

      <section anchor="sdp" title="Signalling for RTP sessions">
        <t>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
        parameters:</t>

        <t><list style="hanging">
            <t hangText="RTP Profile:">The name of the RTP profile to be used
            in session. The <xref target="RFC3551">RTP/AVP</xref> and <xref
            target="RFC4585">RTP/AVPF</xref> profiles can interoperate on
            basic level, as can their secure variants <xref
            target="RFC3711">RTP/SAVP</xref> and <xref
            target="RFC5124">RTP/SAVPF</xref>. The secure variants of the
            profiles do not directly interoperate with the non-secure
            variants, due to the presence of additional header fields.</t>

            <t hangText="Transport Information:">Source and destination
            address(s) and ports for RTP and RTCP must be signalled for each
            RTP session. If <xref target="RFC5761">RTP and RTCP
            multiplexing</xref> is to be used, such that a single port is used
            for RTP and RTCP flows, this must be signalled.</t>

            <t hangText="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).</t>
          </list></t>

        <t>Support for exchanging RTCP Bandwidth values to the end-points will
        be necessary, as described in <xref target="RFC3556">"Session
        Description Protocol (SDP) Bandwidth Modifiers for RTP Control
        Protocol (RTCP) Bandwidth"</xref>, 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.</t>
      </section>

      <section title="(Lack of) Signalling for Payload Format Changes">
        <t>As discussed in <xref target="sdp"></xref>, 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.</t>
      </section>
    </section>

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

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

      <t>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.</t>
    </section>

    <section title="RTP and RTCP Guidelines">
      <t>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.</t>

      <t>Different informational documents provide guidelines to the use and
      particularly the extension of RTP and RTCP, including the following:
      <xref target="RFC2736">Guidelines for Writers of RTP Payload Format
      Specifications</xref> and <xref target="RFC5968">Guidelines for
      Extending the RTP Control Protocol</xref>.</t>
    </section>

    <section title="RTP Optimizations">
      <t>This section discusses some optimizations that makes RTP/RTCP work
      better and more efficient and therefore are considered.</t>

      <section title="RTP and RTCP Multiplexing">
        <t>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 <xref target="RFC5761"></xref>
        is REQUIRED.</t>

        <t>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.</t>
      </section>

      <section title="Reduced Size RTCP">
        <t>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
        share.</t>

        <t>RFC5506 <xref target="RFC5506">"Support for Reduced-Size Real-Time
        Transport Control Protocol (RTCP): Opportunities and
        Consequences"</xref> 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.</t>

        <t>Support for RFC5506 is REQUIRED.</t>
      </section>

      <section title="Symmetric RTP/RTCP">
        <t>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
        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.</t>

        <t>Using <xref target="RFC4961">Symmetric RTP and RTCP</xref> is
        REQURIED.</t>
      </section>

      <section title="CNAME generation">
        <t>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.</t>

        <t>The <xref target="RFC3550">RTP specification</xref> 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
        <xref target="I-D.ietf-avt-rtp-cnames">"Guidelines for Choosing RTP
        Control Protocol (RTCP) Canonical Names (CNAMEs)"</xref> is
        RECOMMENDED, since this addresses both concerns.</t>
      </section>
    </section>

    <section title="RTP Extensions">
      <t>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.</t>

      <section title="RTP Conferencing Extensions">
        <t>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.</t>

        <t>An number of conferencing topologies are defined in <xref
        target="RFC5117"></xref> out of the which the following ones are the
        more common (and most likely in practice workable) ones:</t>

        <t>1) RTP Translator (Relay) with Only Unicast Paths (RFC 5117,
        section 3.3)</t>

        <t>2) RTP Mixer with Only Unicast Paths (RFC 5117, section 3.4)</t>

        <t>3) Point to Multipoint Using a Video Switching MCU (RFC 5117,
        section 3.5)</t>

        <t>4) Point to Multipoint Using Content Modifying MCUs (RFC 5117,
        section 3.6)</t>

        <t>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 <xref target="RFC4585">AVPF</xref> or in <xref
        target="RFC5104">"Codec Control Messages in the RTP Audio-Visual
        Profile with Feedback (AVPF)"</xref>.</t>

        <section title="RTCP Feedback Message: Full Intra Request">
          <t>The Full Intra Request is defined in Section 3.51 and 4.3.1 of
          <xref target="RFC5104"></xref>. 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 supported.</t>
        </section>

        <section title="RTCP Feedback Message: Picture Loss Indicator">
          <t>The Picture Loss Indicator is defined in Section 6.3.1 of <xref
          target="RFC4585"></xref>. 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.</t>
        </section>

        <section title="RTCP Feedback Message: Temporary Maximum Media Stream Bit Rate Request">
          <t>This feedback message is defined in Section 3.5.4 and 4.2.1 in
          <xref target="RFC5104"></xref>. 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 feedback message is supported.</t>
        </section>
      </section>

      <section title="RTP Header Extensions">
        <t>The <xref target="RFC3550">RTP specification</xref> 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 <xref target="RFC5285"></xref>.</t>

        <t>As noted in <xref target="RFC5285"></xref>, the requirement from
        the RTP specification that header extensions are "designed so that the
        header extension may be ignored" <xref target="RFC3550"></xref>
        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 information.</t>

        <t>The RTP rapid synchronisation header extension is recommended, as
        discussed in <xref target="rapid-sync"></xref>.</t>

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

        <t><list style="hanging">
            <t hangText="Transmission Time offsets:"><xref
            target="RFC5450"></xref> 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.</t>

            <t hangText="Associating Time-Codes with RTP Streams:"><xref
            target="RFC5484"></xref> defines how to associate SMPTE times
            codes with the RTP streams.</t>

            <t hangText="Audio Levels indications:">There is ongoing work to
            define RTP header extensions for providing audio levels both from
            a media sender to an mixer <xref
            target="I-D.ietf-avtext-client-to-mixer-audio-level"></xref>, and
            from a mixer to a receiver<xref
            target="I-D.ietf-avtext-mixer-to-client-audio-level"></xref>.</t>
          </list></t>
      </section>

      <section anchor="rapid-sync" title="Rapid Synchronisation Extensions">
        <t>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 <xref
        target="RFC3550">RTP specification</xref>. This basic mechanism can be
        slow, however, so it is RECOMMENDED that the rapid RTP synchronisation
        extensions described in <xref target="RFC6051"></xref> be implemented.
        The rapid synchronisation extensions use the general RTP header
        extension mechanism <xref target="RFC5285"></xref>, which requires
        signalling, but are otherwise backwards compatible.</t>
      </section>
    </section>

    <section title="Improving RTP Transport Robustness">
      <t>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.</t>

      <section title="RTP Retransmission">
        <t>Support for RTP retransmission as defined by <xref
        target="RFC4588">"RTP Retransmission Payload Format"</xref> is
        RECOMMENDED.</t>

        <t>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.</t>
      </section>

      <section title="Forward Error Correction">
        <t>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.</t>
      </section>
    </section>

    <section title="RTP Rate Control and Media Adaptation">
      <t>It is REQUIRED to have an RTP Rate Control mechanism using Media
      adaptation to ensure that the generated RTP flows are network
      friendly.</t>

      <t>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
      Control"<xref target="rtp-tfrc"></xref>.</t>
    </section>

    <section title="RTP Performance Monitoring">
      <t>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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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.</t>

      <t>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.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.3550"?>

      <?rfc include='reference.RFC.2733'?>

      <?rfc include='reference.RFC.2736'?>

      <?rfc include='reference.RFC.3551'?>

      <?rfc include='reference.RFC.3556'?>

      <?rfc include='reference.RFC.3711'?>

      <?rfc include='reference.RFC.4585'?>

      <?rfc include='reference.RFC.4588'?>

      <?rfc include='reference.RFC.4961'?>

      <?rfc include='reference.RFC.5104'?>

      <?rfc include='reference.RFC.5109'?>

      <?rfc include='reference.RFC.5117'?>

      <?rfc include='reference.RFC.5124'?>

      <?rfc include='reference.RFC.5285'?>

      <?rfc include='reference.RFC.5450'?>

      <?rfc include='reference.RFC.5484'?>

      <?rfc include='reference.RFC.5506'?>

      <?rfc include='reference.RFC.5761'?>

      <?rfc include='reference.RFC.5968'?>

      <?rfc include='reference.RFC.6051'?>

      <?rfc include='reference.I-D.draft-ietf-avt-rtp-cnames-05'?>

      <?rfc include='reference.I-D.draft-ietf-avtext-mixer-to-client-audio-level-00'?>

      <?rfc include='reference.I-D.draft-ietf-avtext-client-to-mixer-audio-level-00'?>
    </references>

    <references title="Informative References">
      <reference anchor="rtp-tfrc">
        <front>
          <title>RTP with TCP Friendly Rate Control
          (draft-gharai-avtcore-rtp-tfrc-00)</title>

          <author fullname="Ladan Gharai" initials="L." surname="Gharai">
            <organization></organization>
          </author>

          <date day="7" month="March" year="2011" />
        </front>
      </reference>

      <?rfc ?>

      <?rfc include='reference.RFC.2198'?>
    </references>
  </back>
</rfc>