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