RFC 6679
Explicit Congestion Notification (ECN) for RTP over UDP
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.
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
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
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
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.
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
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 667910.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 667910.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 Report10.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.
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
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
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.
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.
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.
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.
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.
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.
[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.
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