tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6679

 
 
 

Explicit Congestion Notification (ECN) for RTP over UDP

Part 3 of 3, p. 42 to 58
Prev RFC Part

 


prevText      Top      Up      ToC       Page 42 
8.  Processing ECN in RTP Translators and Mixers

   RTP translators and mixers that support ECN for RTP are required to
   process and potentially modify or generate ECN marking in RTP
   packets.  They also need to process and potentially modify or
   generate RTCP ECN feedback packets for the translated and/or mixed
   streams.  This includes both downstream RTCP reports generated by the
   media sender and also reports generated by the receivers, flowing
   upstream back towards the sender.

8.1.  Transport Translators

   Some translators only perform transport-level translations, such as
   copying packets from one address domain, like from unicast to
   multicast.  They may also perform relaying like copying an incoming
   packet to a number of unicast receivers.  This section details the
   ECN-related actions for RTP and RTCP.

Top      Up      ToC       Page 43 
   For RTP data packets, the translator, which does not modify the media
   stream, SHOULD copy the ECN bits unchanged from the incoming to the
   outgoing datagrams, unless the translator itself is overloaded and
   experiencing congestion, in which case it may mark the outgoing
   datagrams with an ECN-CE mark.

   A transport translator does not modify RTCP packets.  However, it
   MUST perform the corresponding transport translation of the RTCP
   packets as it does with RTP packets being sent from the same source/
   endpoint.

8.2.  Fragmentation and Reassembly in Translators

   An RTP translator may fragment or reassemble RTP data packets without
   changing the media encoding and without reference to the congestion
   state of the networks it bridges.  An example of this might be to
   combine packets of a voice-over-IP stream coded with one 20 ms frame
   per RTP packet into new RTP packets with two 20 ms frames per packet,
   thereby reducing the header overhead and thus stream bandwidth, at
   the expense of an increase in latency.  If multiple data packets are
   re-encoded into one, or vice versa, the RTP translator MUST assign
   new sequence numbers to the outgoing packets.  Losses in the incoming
   RTP packet stream may also induce corresponding gaps in the outgoing
   RTP sequence numbers.  An RTP translator MUST rewrite RTCP packets to
   make the corresponding changes to their sequence numbers and to
   reflect the impact of the fragmentation or reassembly.  This section
   describes how that rewriting is to be done for RTCP ECN feedback
   packets.  Section 7.2 of [RFC3550] describes general procedures for
   other RTCP packet types.

   The processing of arriving RTP packets for this case is as follows.
   If an ECN-marked packet is split into two, then both the outgoing
   packets MUST be ECN marked identically to the original; if several
   ECN-marked packets are combined into one, the outgoing packet MUST be
   either ECN-CE marked or dropped if any of the incoming packets are
   ECN-CE marked.  If the outgoing combined packet is not ECN-CE marked,
   then it MUST be ECT marked if any of the incoming packets were ECT
   marked.

   RTCP ECN feedback packets (Section 5.1) contain seven fields that are
   rewritten in an RTP translator that fragments or reassembles packets:
   the extended highest sequence number, the duplication counter, the
   Lost Packets Counter, the ECN-CE counter, and not-ECT counter, the
   ECT(0) counter, and the ECT(1) counter.  The RTCP XR report block for
   ECN summary information (Section 5.2) includes all of these fields
   except the extended highest sequence number, which is present in the

Top      Up      ToC       Page 44 
   report block in an SR or RR packet.  The procedures for rewriting
   these fields are the same for both the RTCP ECN feedback packet and
   the RTCP XR ECN summary packet.

   When receiving an RTCP ECN feedback packet for the translated stream,
   an RTP translator first determines the range of packets to which the
   report corresponds.  The extended highest sequence number in the RTCP
   ECN feedback packet (or in the RTCP SR/RR packet contained within the
   compound packet, in the case of RTCP XR ECN Summary Reports)
   specifies the end sequence number of the range.  For the first RTCP
   ECN feedback packet received, the initial extended sequence number of
   the range may be determined by subtracting the sum of the Lost
   Packets Counter, the ECN-CE counter, the not-ECT counter, the ECT(0)
   counter and the ECT(1) counter minus the duplication counter, from
   the extended highest sequence number.  For subsequent RTCP ECN
   feedback packets, the starting sequence number may be determined as
   being one after the extended highest sequence number of the previous
   RTCP ECN feedback packet received from the same SSRC.  These values
   are in the sequence number space of the translated packets.

   Based on its knowledge of the translation process, the translator
   determines the sequence number range for the corresponding original,
   pre-translation, packets.  The extended highest sequence number in
   the RTCP ECN feedback packet is rewritten to match the final sequence
   number in the pre-translation sequence number range.

   The translator then determines the ratio, R, of the number of packets
   in the translated sequence number space (numTrans) to the number of
   packets in the pre-translation sequence number space (numOrig) such
   that R = numTrans / numOrig.  The counter values in the RTCP ECN
   Feedback Report are then scaled by dividing each of them by R.  For
   example, if the translation process combines two RTP packets into
   one, then numOrig will be twice numTrans, giving R=0.5, and the
   counters in the translated RTCP ECN feedback packet will be twice
   those in the original.

   The ratio, R, may have a value that leads to non-integer multiples of
   the counters when translating the RTCP packet.  For example, a Voice
   over IP (VoIP) translator that combines two adjacent RTP packets into
   one if they contain active speech data, but passes comfort noise
   packets unchanged, would have an R value of between 0.5 and 1.0
   depending on the amount of active speech.  Since the counter values
   in the translated RTCP report are integer values, rounding will be
   necessary in this case.

   When rounding counter values in the translated RTCP packet, the
   translator should try to ensure that they sum to the number of RTP
   packets in the pre-translation sequence number space (numOrig).  The

Top      Up      ToC       Page 45 
   translator should also try to ensure that no non-zero counter is
   rounded to a zero value, unless the pre-translated values are zero,
   since that will lose information that a particular type of event has
   occurred.  It is recognised that it may be impossible to satisfy both
   of these constraints; in such cases, it is better to ensure that no
   non-zero counter is mapped to a zero value, since this preserves
   congestion adaptation and helps the RTCP-based ECN initiation
   process.

   One should be aware of the impact this type of translator has on the
   measurement of packet duplication.  A translator performing
   aggregation and most likely also an fragmenting translator will
   suppress any duplication happening prior to itself.  Thus, the
   reports and what is being scaled will only represent packet
   duplication happening from the translator to the receiver reporting
   on the flow.

   It should be noted that scaling the RTCP counter values in this way
   is meaningful only on the assumption that the level of congestion in
   the network is related to the number of packets being sent.  This is
   likely to be a reasonable assumption in the type of environment where
   RTP translators that fragment or reassemble packets are deployed, as
   their entire purpose is to change the number of packets being sent to
   adapt to known limitations of the network, but is not necessarily
   valid in general.

   The rewritten RTCP ECN Feedback Report is sent from the other side of
   the translator to that from which it arrived (as part of a compound
   RTCP packet containing other translated RTCP packets, where
   appropriate).

8.3.  Generating RTCP ECN Feedback in Media Transcoders

   An RTP translator that acts as a media transcoder cannot directly
   forward RTCP packets corresponding to the transcoded stream, since
   those packets will relate to the non-transcoded stream and will not
   be useful in relation to the transcoded RTP flow.  Such a transcoder
   will need to interpose itself into the RTCP flow, acting as a proxy
   for the receiver to generate RTCP feedback in the direction of the
   sender relating to the pre-transcoded stream and acting in place of
   the sender to generate RTCP relating to the transcoded stream to be
   sent towards the receiver.  This section describes how this proxying
   is to be done for RTCP ECN feedback packets.  Section 7.2 of
   [RFC3550] describes general procedures for other RTCP packet types.

   An RTP translator acting as a media transcoder in this manner does
   not have its own SSRC and hence is not visible to other entities at
   the RTP layer.  RTCP ECN feedback packets and RTCP XR report blocks

Top      Up      ToC       Page 46 
   for ECN summary information that are received from downstream relate
   to the translated stream and so must be processed by the translator
   as if they were the original media source.  These reports drive the
   congestion control loop and media adaptation between the translator
   and the downstream receiver.  If there are multiple downstream
   receivers, a logically separate transcoder instance must be used for
   each receiver and must process RTCP ECN Feedback and Summary Reports
   independently of the other transcoder instances.  An RTP translator
   acting as a media transcoder in this manner MUST NOT forward RTCP ECN
   feedback packets or RTCP XR ECN Summary Reports from downstream
   receivers in the upstream direction.

   An RTP translator acting as a media transcoder will generate RTCP
   reports upstream towards the original media sender, based on the
   reception quality of the original media stream at the translator.
   The translator will run a separate congestion control loop and media
   adaptation between itself and the media sender for each of its
   downstream receivers and must generate RTCP ECN feedback packets and
   RTCP XR ECN Summary Reports for that congestion control loop using
   the SSRC of that downstream receiver.

8.4.  Generating RTCP ECN Feedback in Mixers

   An RTP mixer terminates one-or-more RTP flows, combines them into a
   single outgoing media stream, and transmits that new stream as a
   separate RTP flow.  A mixer has its own SSRC and is visible to other
   participants in the session at the RTP layer.

   An ECN-aware RTP mixer must generate RTCP ECN feedback packets and
   RTCP XR report blocks for ECN summary information relating to the RTP
   flows it terminates, in exactly the same way it would if it were an
   RTP receiver.  These reports form part of the congestion control loop
   between the mixer and the media senders generating the streams it is
   mixing.  A separate control loop runs between each sender and the
   mixer.

   An ECN-aware RTP mixer will negotiate and initiate the use of ECN on
   the mixed RTP flows it generates and will accept and process RTCP ECN
   Feedback Reports and RTCP XR report blocks for ECN relating to those
   mixed flows as if it were a standard media sender.  A congestion
   control loop runs between the mixer and its receivers, driven in part
   by the ECN reports received.

   An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR
   ECN Summary Reports from downstream receivers in the upstream
   direction.

Top      Up      ToC       Page 47 
9.  Implementation Considerations

   To allow the use of ECN with RTP over UDP, an RTP implementation
   desiring to support receiving ECN-controlled media streams must
   support reading the value of the ECT bits on received UDP datagrams,
   and an RTP implementation desiring to support sending ECN-controlled
   media streams must support setting the ECT bits in outgoing UDP
   datagrams.  The standard Berkeley sockets API pre-dates the
   specification of ECN and does not provide the functionality that is
   required for this mechanism to be used with UDP flows, making this
   specification difficult to implement portably.

10.  IANA Considerations

10.1.  SDP Attribute Registration

   Following the guidelines in [RFC4566], the IANA has registered one
   new media-level SDP attribute:

   o  Contact name, email address and telephone number: Authors of RFC
      6679

   o  Attribute-name: ecn-capable-rtp

   o  Type of attribute: media-level

   o  Subject to charset: no

   This attribute defines the ability to negotiate the use of ECT (ECN-
   capable transport) for RTP flows running over UDP/IP.  This attribute
   is put in the SDP offer if the offering party wishes to receive an
   ECT flow.  The answering party then includes the attribute in the
   answer if it wishes to receive an ECT flow.  If the answerer does not
   include the attribute, then ECT MUST be disabled in both directions.

10.2.  RTP/AVPF Transport-Layer Feedback Message

   The IANA has registered one new RTP/AVPF Transport-Layer Feedback
   Message in the table of FMT values for RTPFB Payload Types [RFC4585]
   as defined in Section 5.1:

      Name:          RTCP-ECN-FB
      Long name:     RTCP ECN Feedback
      Value:         8
      Reference:     RFC 6679

Top      Up      ToC       Page 48 
10.3.  RTCP Feedback SDP Parameter

   The IANA has registered one new SDP "rtcp-fb" attribute "nack"
   parameter "ecn" in the SDP ("ack" and "nack" Attribute Values)
   registry.

      Value name:     ecn
      Long name:      Explicit Congestion Notification
      Usable with:    nack
      Reference:      RFC 6679

10.4.  RTCP XR Report Blocks

   The IANA has registered one new RTCP XR Block Type as defined in
   Section 5.2:

      Block Type: 13
      Name:       ECN Summary Report
      Reference:  RFC 6679

10.5.  RTCP XR SDP Parameter

   The IANA has registered one new RTCP XR SDP Parameter "ecn-sum" in
   the "RTCP XR SDP Parameters" registry.

      Parameter name      XR block (block type and name)
      --------------      ------------------------------------
      ecn-sum             13  ECN Summary Report

10.6.  STUN Attribute

   A new STUN [RFC5389] attribute in the comprehension-optional range
   under IETF Review (0x8000-0xFFFF) has been assigned to the ECN-CHECK
   STUN attribute (0x802D) defined in Section 7.2.2.  The STUN attribute
   registry can currently be found at:
   http://www.iana.org/assignments/stun-parameters.

10.7.  ICE Option

   A new ICE option "rtp+ecn" has been registered in the "ICE Options"
   registry created by [RFC6336].

11.  Security Considerations

   The use of ECN with RTP over UDP as specified in this document has
   the following known security issues that need to be considered.

Top      Up      ToC       Page 49 
   External threats to the RTP and RTCP traffic:

   Denial of Service affecting RTCP:  An attacker that can modify the
      traffic between the media sender and a receiver can achieve either
      of two things: 1) report a lot of packets as being congestion
      experience marked, thus forcing the sender into a congestion
      response; or 2) ensure that the sender disables the usage of ECN
      by reporting failures to receive ECN by changing the counter
      fields.  This can also be accomplished by injecting false RTCP
      packets to the media sender.  Reporting a lot of ECN-CE-marked
      traffic is likely the more efficient denial-of-service tool as
      that may likely force the application to use the lowest possible
      bitrates.  The prevention against an external threat is to
      integrity protect the RTCP feedback information and authenticate
      the sender.

   Information leakage:  The ECN feedback mechanism exposes the
      receiver's perceived packet loss and the packets it considers to
      be ECN-CE marked.  This is mostly not considered sensitive
      information.  If it is considered sensitive, the RTCP feedback
      should be encrypted.

   Changing the ECN bits:  An on-path attacker that sees the RTP packet
      flow from sender to receiver and who has the capability to change
      the packets can rewrite ECT into ECN-CE, thus leading to erroneous
      congestion response in the sender or receiver.  This denial of
      service against the media quality in the RTP session is impossible
      for an endpoint to protect itself against.  Only network
      infrastructure nodes can detect this illicit re-marking.  It will
      be mitigated by turning off ECN; however, if the attacker can
      modify its response to drop packets, the same vulnerability exist.

   Denial of Service affecting the session setup signalling:  If an
      attacker can modify the session signalling, it can prevent the
      usage of ECN by removing the signalling attributes used to
      indicate that the initiator is capable and willing to use ECN with
      RTP/UDP.  This attack can be prevented by authentication and
      integrity protection of the signalling.  We do note that any
      attacker that can modify the signalling has more interesting
      attacks they can perform than prevent the usage of ECN, like
      inserting itself as a middleman in the media flows enabling wire-
      tapping also for an off-path attacker.

   Threats that exist from misbehaving senders or receivers:

   Receivers cheating:  A receiver may attempt to cheat and fail to
      report reception of ECN-CE-marked packets.  The benefit for a
      receiver cheating in its reporting would be to get an unfair

Top      Up      ToC       Page 50 
      bitrate share across the resource bottleneck.  It is far from
      certain that a receiver would be able to get a significant larger
      share of the resources.  That assumes a high enough level of
      aggregation that there are flows to acquire shares from.  The risk
      of cheating is that failure to react to congestion results in
      packet loss and increased path delay.

   Receivers misbehaving:  A receiver may prevent the usage of ECN in an
      RTP session by reporting itself as non-ECN capable, forcing the
      sender to turn off usage of ECN.  In a point-to-point scenario,
      there is little incentive to do this as it will only affect the
      receiver, thus failing to utilise an optimisation.  For multi-
      party sessions, some motivation exists for why a receiver would
      misbehave as it can prevent the other receivers from using ECN.
      As an insider into the session, it is difficult to determine if a
      receiver is misbehaving or simply incapable, making it basically
      impossible in the incremental deployment phase of ECN for RTP
      usage to determine this.  If additional information about the
      receivers and the network is known, it might be possible to deduce
      that a receiver is misbehaving.  If it can be determined that a
      receiver is misbehaving, the only response is to exclude it from
      the RTP session and ensure that it no longer has any valid
      security context to affect the session.

   Misbehaving senders:  The enabling of ECN gives the media packets a
      higher degree of probability to reach the receiver compared to
      not-ECT-marked ones on an ECN-capable path.  However, this is no
      magic bullet, and failure to react to congestion will most likely
      only slightly delay a network buffer over-run, in which its
      session also will experience packet loss and increased delay.
      There is some possibility that the media sender's traffic will
      push other traffic out of the way without being affected too
      negatively.  However, we do note that a media sender still needs
      to implement congestion control functions to prevent the media
      from being badly affected by congestion events.  Thus, the
      misbehaving sender is getting an unfair share.  This can only be
      detected and potentially prevented by network monitoring and
      administrative entities.  See Section 7 of [RFC3168] for more
      discussion of this issue.

   We note that the endpoint security functions needed to prevent an
   external attacker from interfering with the signalling are source
   authentication and integrity protection.  To prevent information
   leakage from the feedback packets, encryption of the RTCP is also
   needed.  For RTP, multiple possible solutions exist depending on the
   application context.  Secure RTP (SRTP) [RFC3711] does satisfy the
   requirement to protect this mechanism.  Note, however, that when
   using SRTP in group communication scenarios, different parties might

Top      Up      ToC       Page 51 
   share the same security context; in this case, the authentication
   mechanism only shows that one of those parties is involved, not
   necessarily which one.  IPsec [RFC4301] and DTLS [RFC6347] can also
   provide the necessary security functions.

   The signalling protocols used to initiate an RTP session also need to
   be source authenticated and integrity protected to prevent an
   external attacker from modifying any signalling.  An appropriate
   mechanism to protect the used signalling needs to be used.  For SIP/
   SDP, ideally Secure MIME (S/MIME) [RFC5751] would be used.  However,
   with the limited deployment, a minimal mitigation strategy is to
   require use of SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least
   accomplish hop-by-hop protection.

   We do note that certain mitigation methods will require network
   functions.

12.  Examples of SDP Signalling

   This section contains a few different examples of the signalling
   mechanism defined in this specification in an SDP context.  If there
   are discrepancies between these examples and the specification text,
   the specification text is definitive.

Top      Up      ToC       Page 52 
12.1.  Basic SDP Offer/Answer

   This example is a basic offer/answer SDP exchange, assumed done by
   SIP (not shown).  The intention is to establish a basic audio session
   point-to-point between two users.

   The Offer:

      v=0
      o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4
      s=VoIP call
      i=SDP offer for VoIP call with ICE and ECN for RTP
      b=AS:128
      b=RR:2000
      b=RS:2500
      a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
      a=ice-ufrag:9uB6
      a=ice-options:rtp+ecn
      t=0 0
      m=audio 45664 RTP/AVPF 97 98 99
      c=IN IP4 192.0.2.3
      a=rtpmap:97 G719/48000/1
      a=fmtp:97 maxred=160
      a=rtpmap:98 AMR-WB/16000/1
      a=fmtp:98 octet-align=1; mode-change-capability=2
      a=rtpmap:99 PCMA/8000/1
      a=maxptime:160
      a=ptime:20
      a=ecn-capable-rtp: ice rtp ect=0 mode=setread
      a=rtcp-fb:* nack ecn
      a=rtcp-fb:* trr-int 1000
      a=rtcp-xr:ecn-sum
      a=rtcp-rsize
      a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host
      a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
         10.0.1.4 rport 8998

   This SDP offer presents a single media stream with 3 media payload
   types.  It proposes to use ECN with RTP, with the ICE-based
   initialisation being preferred over the RTP/RTCP one.  Leap of faith
   is not suggested to be used.  The offerer is capable of both setting
   and reading the ECN bits.  In addition, the use of both the RTCP ECN
   feedback packet and the RTCP XR ECN Summary Report are supported.
   ICE is also proposed with two candidates.  It also supports reduced-
   size RTCP and can use it.

Top      Up      ToC       Page 53 
   The Answer:

      v=0
      o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235
      s=VoIP call
      i=SDP offer for VoIP call with ICE and ECN for RTP
      b=AS:128
      b=RR:2000
      b=RS:2500
      a=ice-pwd:asd88fgpdd777uzjYhagZg
      a=ice-ufrag:8hhY
      a=ice-options:rtp+ecn
      t=0 0
      m=audio 53879 RTP/AVPF 97 99
      c=IN IP4 198.51.100.235
      a=rtpmap:97 G719/48000/1
      a=fmtp:97 maxred=160
      a=rtpmap:99 PCMA/8000/1
      a=maxptime:160
      a=ptime:20
      a=ecn-capable-rtp: ice ect=0 mode=readonly
      a=rtcp-fb:* nack ecn
      a=rtcp-fb:* trr-int 1000
      a=rtcp-xr:ecn-sum
      a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ host

   The answer confirms that only one media stream will be used.  One RTP
   payload type was removed.  ECN capability was confirmed, and the
   initialisation method will be ICE.  However, the answerer is only
   capable of reading the ECN bits, which means that ECN can only be
   used for RTP flowing from the offerer to the answerer.  ECT always
   set to 0 will be used in both directions.  Both the RTCP ECN feedback
   packet and the RTCP XR ECN Summary Report will be used.  Reduced-size
   RTCP will not be used as the answerer has not indicated support for
   it in the answer.

Top      Up      ToC       Page 54 
12.2.  Declarative Multicast SDP

   The session below describes an Any-Source Multicast using a session
   with a single media stream.

      v=0
      o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235
      s=Multicast SDP session using ECN for RTP
      i=Multicasted audio chat using ECN for RTP
      b=AS:128
      t=3502892703 3502910700
      m=audio 56144 RTP/AVPF 97
      c=IN IP4 233.252.0.212/127
      a=rtpmap:97 g719/48000/1
      a=fmtp:97 maxred=160
      a=maxptime:160
      a=ptime:20
      a=ecn-capable-rtp: rtp mode=readonly; ect=0
      a=rtcp-fb:* nack ecn
      a=rtcp-fb:* trr-int 1500
      a=rtcp-xr:ecn-sum

   This is a declarative SDP example and indicates required
   functionality in the consumer of the SDP.  The initialisation method
   required is the RTP/RTCP-based one, indicated by the "a=ecn-capable-
   rtp: rtp ..." line.  Receivers are required to be able to read ECN
   marks ("mode=readonly"), and the ECT value is recommended to be set
   to 0 always ("ect=0").  The ECN usage in this session requires both
   ECN feedback and RTCP XR ECN Summary Reports, and their use is
   indicated through the "a=rtcp-fb:" and "a=rtcp-xr:ecn-sum" lines.

13.  Acknowledgments

   The authors wish to thank the following individuals for their reviews
   and comments: Thomas Belling, Bob Briscoe, Roni Even, Kevin P.
   Flemming, Tomas Frankkila, Christian Groves, Christer Holmgren,
   Cullen Jennings, Tom Van Caenegem, Simo Veikkolainen, Bill Ver Steeg,
   Dan Wing, Qin Wu, and Lei Zhu.

Top      Up      ToC       Page 55 
14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

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

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611,
              November 2003.

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

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

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

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification",
              RFC 5348, September 2008.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6336]  Westerlund, M. and C. Perkins, "IANA Registry for
              Interactive Connectivity Establishment (ICE) Options",
              RFC 6336, July 2011.

Top      Up      ToC       Page 56 
14.2.  Informative References

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC2762]  Rosenberg, J. and H. Schulzrinne, "Sampling of the Group
              Membership in RTP", RFC 2762, February 2000.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

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

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
              Congestion Notification (ECN) Signaling with Nonces",
              RFC 3540, June 2003.

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

   [RFC3569]  Bhattacharyya, S., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, 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.

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

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

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

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

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 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.

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

   [RFC5630]  Audet, F., "The Use of the SIPS URI Scheme in the Session
              Initiation Protocol (SIP)", RFC 5630, October 2009.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC5760]  Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
              Protocol (RTCP) Extensions for Single-Source Multicast
              Sessions with Unicast Feedback", RFC 5760, February 2010.

   [RFC6189]  Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
              Path Key Agreement for Unicast Secure RTP", RFC 6189,
              April 2011.

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

Top      Up      ToC       Page 58 
Authors' Addresses

   Magnus Westerlund
   Ericsson
   Farogatan 6
   SE-164 80 Kista
   Sweden
   Phone: +46 10 714 82 87
   EMail: magnus.westerlund@ericsson.com


   Ingemar Johansson
   Ericsson
   Laboratoriegrand 11
   SE-971 28 Lulea
   Sweden
   Phone: +46 73 0783289
   EMail: ingemar.s.johansson@ericsson.com


   Colin Perkins
   University of Glasgow
   School of Computing Science
   Glasgow  G12 8QQ
   United Kingdom
   EMail: csp@csperkins.org


   Piers O'Hanlon
   University of Oxford
   Oxford Internet Institute
   1 St Giles
   Oxford  OX1 3JS
   United Kingdom
   EMail: piers.ohanlon@oii.ox.ac.uk


   Ken Carlberg
   G11
   1600 Clarendon Blvd
   Arlington, VA
   USA
   EMail: carlberg@g11.org.uk