draft-ietf-avt-ecn-for-rtp-00.txt   draft-ietf-avt-ecn-for-rtp-01.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft I. Johansson Internet-Draft I. Johansson
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: August 23, 2010 C. Perkins Expires: September 9, 2010 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
February 19, 2010 March 8, 2010
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avt-ecn-for-rtp-00 draft-ietf-avt-ecn-for-rtp-01
Abstract Abstract
This document specifies how explicit congestion notification (ECN) This document specifies how explicit congestion notification (ECN)
can be used with RTP/UDP flows that use RTCP as feedback mechanism. can be used with RTP/UDP flows that use RTCP as feedback mechanism.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12 4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12
4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 17 4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 17
4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22 4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22
4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 26 4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 26
5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29
5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29 5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29
5.2. RTCP XR Report block for ECN summary information . . . . . 32 5.2. RTCP XR Report block for ECN summary information . . . . . 32
5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 33 5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 33
6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 36 6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 36
6.1. Fragmentation and Reassembly in Translators . . . . . . . 36 6.1. Fragmentation and Reassembly in Translators . . . . . . . 36
6.2. Generating RTCP ECN Feedback in Translators . . . . . . . 36 6.2. Generating RTCP ECN Feedback in Translators . . . . . . . 37
6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 37 6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 37
7. Implementation considerations . . . . . . . . . . . . . . . . 37 7. Implementation considerations . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 37 8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 38
8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 38 8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 38
8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 38 8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 38
8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 38 8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 38
8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 38 8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 41 10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 41
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42
12.2. Informative References . . . . . . . . . . . . . . . . . . 42 12.2. Informative References . . . . . . . . . . . . . . . . . . 42
skipping to change at page 3, line 30 skipping to change at page 3, line 30
limited resources and coverage on a radio link, or other reasons. limited resources and coverage on a radio link, or other reasons.
This congestion signal allows applications to reduce their This congestion signal allows applications to reduce their
transmission rate in a controlled manner, rather than responding to transmission rate in a controlled manner, rather than responding to
uncontrolled packet loss, and so improves the user experience while uncontrolled packet loss, and so improves the user experience while
benefiting the network. benefiting the network.
The introduction of ECN into the Internet requires changes to both The introduction of ECN into the Internet requires changes to both
the network and transport layers. At the network layer, IP the network and transport layers. At the network layer, IP
forwarding has to be updated to allow routers to mark packets, rather forwarding has to be updated to allow routers to mark packets, rather
than discarding them in times of congestion [RFC3168]. In addition, than discarding them in times of congestion [RFC3168]. In addition,
transport protocols have to be modified to inform that sender that transport protocols have to be modified to inform the sender that ECN
ECN marked packets are being received, so it can respond to the marked packets are being received, so it can respond to the
congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have
been updated to support ECN, but to date there is no specification been updated to support ECN, but to date there is no specification
how UDP-based transports, such as RTP [RFC3550], can use ECN. This how UDP-based transports, such as RTP [RFC3550], can use ECN. This
is due to the lack of feedback mechanism directly in UDP. Instead is due to the lack of feedback mechanism directly in UDP. Instead
the protocol on top of UDP needs to provide that feedback, which for the protocol on top of UDP needs to provide that feedback, which for
RTP is RTCP. RTP is RTCP.
The remainder of this memo is structured as follows. We start by The remainder of this memo is structured as follows. We start by
describing the conventions, definitions and acronyms used in this describing the conventions, definitions and acronyms used in this
memo in Section 2, and the design rationale and applicability in memo in Section 2, and the design rationale and applicability in
skipping to change at page 6, line 44 skipping to change at page 6, line 44
Topo-Point-to-Point: This is a standard unicast flow. ECN may be Topo-Point-to-Point: This is a standard unicast flow. ECN may be
used with RTP in this topology in an analogous manner to its use used with RTP in this topology in an analogous manner to its use
with other unicast transport protocols, with RTCP conveying ECN with other unicast transport protocols, with RTCP conveying ECN
feedback messages. feedback messages.
Topo-Multicast: This is either an any source multicast (ASM) group Topo-Multicast: This is either an any source multicast (ASM) group
with potentially several active senders and multicast RTCP with potentially several active senders and multicast RTCP
feedback, or a source specific multicast (SSM) group with a single feedback, or a source specific multicast (SSM) group with a single
sender and unicast RTCP feedback from receivers. RTCP is designed sender and unicast RTCP feedback from receivers. RTCP is designed
to scale to large group sizes while avoiding feedback implosion to scale to large group sizes while avoiding feedback implosion
(see Section 6.2 of [RFC3550], [RFC4585], and (see Section 6.2 of [RFC3550], [RFC4585], and [RFC5760]), and can
[I-D.ietf-avt-rtcpssm]), and can be used by a sender to determine be used by a sender to determine if all its receivers, and the
if all its receivers, and the network paths to those receivers, network paths to those receivers, support ECN (see Section 4.2).
support ECN (see Section 4.2). It is somewhat more difficult to It is somewhat more difficult to determine if all network paths
determine if all network paths from all senders to all receivers from all senders to all receivers support ECN. Accordingly, we
support ECN. Accordingly, we allow ECN to be used by an RTP allow ECN to be used by an RTP sender using multicast UDP provided
sender using multicast UDP provided the sender has verified that the sender has verified that the paths to all its known receivers
the paths to all its known receivers support ECN, and irrespective support ECN, and irrespective of whether the paths from other
of whether the paths from other senders to their receivers support senders to their receivers support ECN. Note that group
ECN. Note that group membership may change during the lifetime of membership may change during the lifetime of a multicast RTP
a multicast RTP session, potentially introducing new receivers session, potentially introducing new receivers that are not ECN
that are not ECN capable. Senders must use the mechanisms capable. Senders must use the mechanisms described in Section 4.4
described in Section 4.4 to monitor that all receivers continue to to monitor that all receivers continue to support ECN, and needs
support ECN, and needs to fallback to non-ECN use if they do not. to fallback to non-ECN use if they do not.
Topo-Translator: An RTP translator is an RTP-level middlebox that is Topo-Translator: An RTP translator is an RTP-level middlebox that is
invisible to the other participants in the RTP session (although invisible to the other participants in the RTP session (although
it is usually visible in the associated signalling session). it is usually visible in the associated signalling session).
There are two types of RTP translator: those do not modify the There are two types of RTP translator: those do not modify the
media stream, and are concerned with transport parameters, for media stream, and are concerned with transport parameters, for
example a multicast to unicast gateway; and those that do modify example a multicast to unicast gateway; and those that do modify
the media stream, for example transcoding between different media the media stream, for example transcoding between different media
codecs. A single RTP session traverses the translator, and the codecs. A single RTP session traverses the translator, and the
translator must rewrite RTCP messages passing through it to match translator must rewrite RTCP messages passing through it to match
skipping to change at page 12, line 27 skipping to change at page 12, line 27
increased congestion levels are likely to cause unpredictable packet increased congestion levels are likely to cause unpredictable packet
losses that decrease the media quality more than would reducing the losses that decrease the media quality more than would reducing the
data rate). To enable the sender to verify the ECN nonce, the sender data rate). To enable the sender to verify the ECN nonce, the sender
must learn the sequence number of all packets that was either CE must learn the sequence number of all packets that was either CE
marked or lost, otherwise it can't correctly exclude these packet marked or lost, otherwise it can't correctly exclude these packet
from the ECN nonce sum. This is done using a new RTCP XR report from the ECN nonce sum. This is done using a new RTCP XR report
type, the Nonce Report, that contains the nonce sums and indicating type, the Nonce Report, that contains the nonce sums and indicating
the lost or ECN-CE marked packets using a run length encoded bit- the lost or ECN-CE marked packets using a run length encoded bit-
vector. Due to the size of ECN Nonce Reports, and as most RTP-based vector. Due to the size of ECN Nonce Reports, and as most RTP-based
applications have little incentive to lie about ECN marks, the use of applications have little incentive to lie about ECN marks, the use of
the ECN none is OPTIONAL. the ECN nonce is OPTIONAL.
In the detailed specification of the behaviour below, the different In the detailed specification of the behaviour below, the different
functions the general case will first be discussed. In cases special functions in the general case will first be discussed. In case
considerations are needed for middleboxes, multicast usage etc, those special considerations are needed for middleboxes, multicast usage
will be specially discussed in related subsections. etc, those will be specially discussed in related subsections.
4.1. Negotiation of ECN Capability 4.1. Negotiation of ECN Capability
The first stage of ECN negotiation for RTP-over-UDP is to signal the The first stage of ECN negotiation for RTP-over-UDP is to signal the
capability to use ECN. This includes negotiating if ECN is to be capability to use ECN. This includes negotiating if ECN is to be
used symmetrically, the method for initial ECT verification, and used symmetrically, the method for initial ECT verification, and
whether the ECN nonce is to be used. This memo defines the mappings whether the ECN nonce is to be used. This memo defines the mappings
of this information onto SDP for both declarative and offer/answer of this information onto SDP for both declarative and offer/answer
usage. There is one SDP extension to indicate if ECN support should usage. There is one SDP extension to indicate if ECN support should
be used, and the method for initiation. In addition an ICE parameter be used, and the method for initiation. In addition an ICE parameter
skipping to change at page 13, line 51 skipping to change at page 13, line 51
When the "mode=" parameter is omitted it is assumed that the node When the "mode=" parameter is omitted it is assumed that the node
has "setread" capabilities. This option can provide for an early has "setread" capabilities. This option can provide for an early
indication that ECN cannot be used in a session. This would be indication that ECN cannot be used in a session. This would be
case when both the offerer and answerer set the "mode=" parameter case when both the offerer and answerer set the "mode=" parameter
to "setonly" or "readonly", or when an RTP sender entity considers to "setonly" or "readonly", or when an RTP sender entity considers
offering "readonly". offering "readonly".
o The "nonce" parameter may be used to signal whether the ECN nonce o The "nonce" parameter may be used to signal whether the ECN nonce
is to be used in the session. This parameter takes two values; is to be used in the session. This parameter takes two values;
"nonce=1" for nonce proposed or shall be used, and "nonce=0" for "nonce=1" for nonce proposed or shall be used, and "nonce=0" for
no nonce. no nonce. If this parameter is not specified, the default is no
nonce.
o The "ect" parameter makes it possible to express the preferred ECT o The "ect" parameter makes it possible to express the preferred ECT
marking. This is either random (default), 0, or 1. If the ECN marking. This is either "random", "0", or "1", with "0" being
nonce is used then this parameter MUST be ignored, and random ECT implied if not specified. The "ect" parameter describes a
is implied. The "ect" parameter describes a receiver preference, receiver preference, and is useful in the case where the receiver
and is useful in the case where the receiver knows it is behind a knows it is behind a link using IP header compression, the
link using IP header compression, the efficiency of which would be efficiency of which would be seriously disrupted if it were to
seriously disrupted if it were to receive packets with randomly receive packets with randomly chosen ECT marks. If the ECN nonce
chosen ECT marks. is used then this parameter MUST be ignored, and random ECT is
implied; if the ECN nonce is not used, it is RECOMMENDED that
ECT(0) marking be used.
The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is
as follows: as follows:
ecn-attribute = "a=ecn-capable-rtp:" SP init-list SP parm-list ecn-attribute = "a=ecn-capable-rtp:" SP init-list SP parm-list
init-list = init-value *("," init-value) init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token init-ext = token
parm-list = parm-value *(";" SP parm-value) parm-list = parm-value *(";" SP parm-value)
parm-value = nonce / mode / ect / parm-ext parm-value = nonce / mode / ect / parm-ext
skipping to change at page 16, line 15 skipping to change at page 16, line 17
When SDP is used in a declarative manner, for example in a multicast When SDP is used in a declarative manner, for example in a multicast
session using SAP, negotiation of session description parameters is session using SAP, negotiation of session description parameters is
not possible. The "a=ecn-capable-rtp" attribute MAY be added to the not possible. The "a=ecn-capable-rtp" attribute MAY be added to the
session description to indicate that the sender will use ECN in the session description to indicate that the sender will use ECN in the
RTP session. The attribute MUST include a single method of RTP session. The attribute MUST include a single method of
initiation. Participants MUST NOT join such a session unless they initiation. Participants MUST NOT join such a session unless they
have the capability to understand ECN-marked UDP packets, implement have the capability to understand ECN-marked UDP packets, implement
the method of initiation, and can generate RTCP ECN feedback (note the method of initiation, and can generate RTCP ECN feedback (note
that having the capability to use ECN doesn't necessarily imply that that having the capability to use ECN doesn't necessarily imply that
the underlying network path between sender and receiver supports the underlying network path between sender and receiver supports
ECN). If the nonce parameter is included the ECN nonce shall be used ECN). If the nonce parameter is included then the ECN nonce SHALL be
in the session. The mode parameter MAY be included also in used in the session. The mode parameter MAY be included also in
declarative usage, to indicate which capability is required by the declarative usage, to indicate which capability is required by the
consumer of the SDP. So for example in a SSM session the consumer of the SDP. So for example in a SSM session the
participants configured with a particular SDP will all be in a media participants configured with a particular SDP will all be in a media
receive only mode, thus mode=readonly will work as the capability of receive only mode, thus mode=readonly will work as the capability of
reporting on the ECN markings in the received is what is required. reporting on the ECN markings in the received is what is required.
The "a=ecn-capable-rtp" attribute MAY be used with RTP media sessions The "a=ecn-capable-rtp" attribute MAY be used with RTP media sessions
using UDP/IP transport. It MUST NOT be used for RTP sessions using using UDP/IP transport. It MUST NOT be used for RTP sessions using
TCP, SCTP, or DCCP transport, or for non-RTP sessions. TCP, SCTP, or DCCP transport, or for non-RTP sessions.
skipping to change at page 20, line 35 skipping to change at page 20, line 44
having performed a successful connectivity check for a candidate, having performed a successful connectivity check for a candidate,
which is nominated for usage. At that point, and provided the chosen which is nominated for usage. At that point, and provided the chosen
candidate is not a relayed address, one performs an additional candidate is not a relayed address, one performs an additional
connectivity check including the here defined STUN attribute "ECT connectivity check including the here defined STUN attribute "ECT
Check" and in an UDP/IP packet that are ECT marked. The STUN server Check" and in an UDP/IP packet that are ECT marked. The STUN server
will upon reception of the packet note the received ECN field value will upon reception of the packet note the received ECN field value
and in its response send an STUN/UDP/IP Packet with ECN field set to and in its response send an STUN/UDP/IP Packet with ECN field set to
not-ECT and also include the ECN check STUN attribute. not-ECT and also include the ECN check STUN attribute.
The STUN ECN check STUN attribute contains one field and a flag. The The STUN ECN check STUN attribute contains one field and a flag. The
flag indicate if the echo field contains a valid value or not. The flag indicates if the echo field contains a valid value or not. The
field is the ECN echo field, and when valid contains the two ECN bits field is the ECN echo field, and when valid contains the two ECN bits
from the packet it echoes back. The ECN check STUN attribute is a from the packet it echoes back. The ECN check STUN attribute is a
comprehension optional attribute. comprehension optional attribute.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V| | Reserved |ECF|V|
skipping to change at page 22, line 30 skipping to change at page 22, line 40
that sender begins sending all RTP data packets as ECT-marked, and that sender begins sending all RTP data packets as ECT-marked, and
its receivers continue sending ECN feedback information via RTCP its receivers continue sending ECN feedback information via RTCP
packets. This section describes procedures for sending ECT-marked packets. This section describes procedures for sending ECT-marked
data, providing ECN feedback information via RTCP, responding to ECN data, providing ECN feedback information via RTCP, responding to ECN
feedback information, and detecting failures and misbehaving feedback information, and detecting failures and misbehaving
receivers. receivers.
4.3.1. Transmission of ECT-marked RTP Packets 4.3.1. Transmission of ECT-marked RTP Packets
After a sender has successfully initiated ECN usage, it SHOULD mark After a sender has successfully initiated ECN usage, it SHOULD mark
all the RTP data packets it sends as ECT. The choice between ECT(0) all the RTP data packets it sends as ECT. The sender SHOULD mark
and ECT(1) is determined by the sender having considered the receiver packets as ECT(0) unless the receiver expresses a preference for
preferencies expressed by the "ect" parameter in the "a=ecn-capable- ECT(1) or random choice using the "ect" parameter in the "a=ecn-
rtp" attribute. If the sender selects a random choice of ECT capable-rtp" attribute; or unless the ECN nonce is in use, in which
marking, the sender MUST record the statistics for the different ECN case random ECT marks MUST be used. If the sender selects a random
values sent. If ECN nonce is activated the sender must record the choice of ECT marking, the sender MUST record the statistics for the
value and calculate the ECN-nonce sum for outgoing packets [RFC3540] different ECN values sent. If ECN nonce is activated the sender must
to allow the use of the ECN-nonce to detect receiver misbehaviour record the value and calculate the ECN-nonce sum for outgoing packets
(see Section 4.4). Guidelines on the random choice of ECT values are [RFC3540] to allow the use of the ECN-nonce to detect receiver
provided in Section 8 of [RFC3540]. misbehaviour (see Section 4.4). Guidelines on the random choice of
ECT values are provided in Section 8 of [RFC3540].
The sender SHALL NOT include ECT marks on outgoing RTCP packets, and The sender SHALL NOT include ECT marks on outgoing RTCP packets, and
SHOULD NOT include ECT marks on any other outgoing control messages SHOULD NOT include ECT marks on any other outgoing control messages
(e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or (e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or
ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are multiplexed ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are multiplexed
on the same UDP port. on the same UDP port.
4.3.2. Reporting ECN Feedback via RTCP 4.3.2. Reporting ECN Feedback via RTCP
An RTP receiver that receives a packet with an ECN-CE mark, or that An RTP receiver that receives a packet with an ECN-CE mark, or that
detects a packet loss, MUST schedule the transmission of an RTCP ECN detects a packet loss, MUST schedule the transmission of an RTCP ECN
feedback packet as soon as possible to report this back to the feedback packet as soon as possible to report this back to the
sender. The feedback RTCP packet sent SHALL consist at least one ECN sender. The feedback RTCP packet sent SHALL consist of at least one
feedback packet (Section 5) reporting on the packets received since ECN feedback packet (Section 5) reporting on the packets received
the last ECN feedback packet, and SHOULD contain an RTCP SR or RR since the last ECN feedback packet, and SHOULD contain an RTCP SR or
packet. The RTP/AVPF profile in early or immediate feedback mode RR packet. The RTP/AVPF profile in early or immediate feedback mode
SHOULD be used where possible, to reduce the interval before feedback SHOULD be used where possible, to reduce the interval before feedback
can be sent. To reduce the size of the feedback message, reduced can be sent. To reduce the size of the feedback message, reduced
size RTCP [RFC5506] MAY be used if supported by the end-points. Both size RTCP [RFC5506] MAY be used if supported by the end-points. Both
RTP/AVPF and reduced size RTCP MUST be negotiated in the session RTP/AVPF and reduced size RTCP MUST be negotiated in the session
set-up signalling before they can be used. ECN Nonce information set-up signalling before they can be used. ECN Nonce information
SHOULD NOT be included in early or immediate reports, only when SHOULD NOT be included in early or immediate reports, only when
regular reports are sent. regular reports are sent.
Every time a regular compound RTCP packet is to be transmitted, the Every time a regular compound RTCP packet is to be transmitted, the
RTP receiver MUST include an RTCP XR ECN summary report Section 5.2 RTP receiver MUST include an RTCP XR ECN summary report Section 5.2
as part of the compound packet. If ECN-nonce is enabled the receiver as part of the compound packet. If ECN-nonce is enabled the receiver
MUST also include an RTCP XR Nonce report packet Section 5.3. It is MUST also include an RTCP XR Nonce report packet Section 5.3. It is
important to configure the RTCP bandwidth (e.g. using an SDP "b=" important to configure the RTCP bandwidth (e.g. using an SDP "b="
line) such that the bit-rate is sufficient for a usage that includes line) such that the bit-rate is sufficient for a usage that includes
these regular summary and none reports, and feedback on ECN-CE these regular summary and nonce reports, and feedback on ECN-CE
events. events.
The multicast feedback implosion problem, that occurs when many The multicast feedback implosion problem, that occurs when many
receivers simultaneously send feedback to a single sender, must also receivers simultaneously send feedback to a single sender, must also
be considered. The RTP/AVPF transmission rules will limit the amount be considered. The RTP/AVPF transmission rules will limit the amount
of feedback that can be sent, avoiding the implosion problem but also of feedback that can be sent, avoiding the implosion problem but also
delaying feedback by varying degrees from nothing up to a full RTCP delaying feedback by varying degrees from nothing up to a full RTCP
reporting interval. As a result, the full extent of a congestion reporting interval. As a result, the full extent of a congestion
situation may take some time to reach the sender, although some situation may take some time to reach the sender, although some
feedback should arrive in a reasonably timely manner , allowing the feedback should arrive in a reasonably timely manner , allowing the
skipping to change at page 24, line 20 skipping to change at page 24, line 30
on both the total number of packet sent per reporting interval and on both the total number of packet sent per reporting interval and
the CE and Packet loss pattern how many bits are required for the CE and Packet loss pattern how many bits are required for
reporting. reporting.
The RTCP packets may be lost, and to avoid the possibility for The RTCP packets may be lost, and to avoid the possibility for
cheating by "losing" the Nonce information for where one is cheating cheating by "losing" the Nonce information for where one is cheating
the nonce coverage needs to be basically complete. Thus the Nonce the nonce coverage needs to be basically complete. Thus the Nonce
reporting SHOULD cover at least the 3 regular reporting intervals. reporting SHOULD cover at least the 3 regular reporting intervals.
The only exception allowed is if the reporting information becomes to The only exception allowed is if the reporting information becomes to
heavy and makes the RTCP report packet become larger than the MTU. heavy and makes the RTCP report packet become larger than the MTU.
In that case a receiver MAY reduced to coverage for the ECN nonce to In that case a receiver MAY reduce the coverage for the ECN nonce to
only the last or two last reporting intervals. A sender should only the last or two last reporting intervals. A sender should
consider the received size report for cases where the coverage is not consider the received size report for cases where the coverage is not
at least three reporting intervals and determine if this may be done at least three reporting intervals and determine if this may be done
to cheat or not. Failure to have reported on all intervals MAY be to cheat or not. Failure to have reported on all intervals MAY be
punished by reducing the congestion safe rate. punished by reducing the congestion safe rate.
The ECN nonce information in the ECN feedback packet consists of both The ECN nonce information in the ECN feedback packet consists of both
a start value for the nonce prior to the first packet in the a start value for the nonce prior to the first packet in the
reporting interval and the final 2-bit XOR sum over all the received reporting interval and the final 2-bit XOR sum over all the received
ECN values, both not-ECT and ECT for the report interval. The report ECN values, both not-ECT and ECT for the report interval. The report
skipping to change at page 26, line 31 skipping to change at page 26, line 42
loss it will be in both media sender and receivers interest to loss it will be in both media sender and receivers interest to
minimise the number and duration of any congestion events as they minimise the number and duration of any congestion events as they
will affect media quality. will affect media quality.
RTP sessions can also suffer from path changes resulting in a non-ECN RTP sessions can also suffer from path changes resulting in a non-ECN
compliant node becoming part of the path. That node may perform compliant node becoming part of the path. That node may perform
either of two actions that has effect on the ECN and application either of two actions that has effect on the ECN and application
functionality. The gravest is if the node drops packets with any ECN functionality. The gravest is if the node drops packets with any ECN
field values other than 00b. This can be detected by the receiver field values other than 00b. This can be detected by the receiver
when it receives a RTCP SR packet indicating that a sender has sent a when it receives a RTCP SR packet indicating that a sender has sent a
a number of packets has not been received. The sender may also number of packets has not been received. The sender may also detect
detect it based on the receivers RTCP RR packet where the extended it based on the receivers RTCP RR packet where the extended sequence
sequence number is not advanced due to the failure to receive number is not advanced due to the failure to receive packets. If the
packets. If the packet loss is less than 100% then packet loss packet loss is less than 100% then packet loss reporting in either
reporting in either the ECN feedback information or RTCP RR will the ECN feedback information or RTCP RR will indicate the situation.
indicate the situation. The other action is to remark a packet from The other action is to remark a packet from ECT to not-ECT. That has
ECT to not-ECT. That has less dire results, however, it should be less dire results, however, it should be detected so that ECN usage
detected so that ECN usage can be suspended to prevent misusing the can be suspended to prevent misusing the network.
network.
The ECN feedback packet allows the sender to compare the number of The ECN feedback packet allows the sender to compare the number of
ECT marked packets of different type with the number it actually ECT marked packets of different type with the number it actually
sent. The number of ECT packets received plus the number of CE sent. The number of ECT packets received plus the number of CE
marked and lost packets should correspond to the number of sent ECT marked and lost packets should correspond to the number of sent ECT
marked packets. If this number doesn't agree there are two likely marked packets. If this number doesn't agree there are two likely
reasons, a translator changing the stream or not carrying the ECN reasons, a translator changing the stream or not carrying the ECN
markings forward, or that some node remarks the packets. In both markings forward, or that some node remarks the packets. In both
cases the usage of ECN is broken on the path. By tracking all the cases the usage of ECN is broken on the path. By tracking all the
different possible ECN field values a sender can quickly detect if different possible ECN field values a sender can quickly detect if
skipping to change at page 27, line 21 skipping to change at page 27, line 29
Upon the detection of a potential failure both the sender and the Upon the detection of a potential failure both the sender and the
receiver can react to mitigate the situation. receiver can react to mitigate the situation.
A receiver that detects a packet loss burst MAY schedule an early A receiver that detects a packet loss burst MAY schedule an early
feedback packet to report this to the sender that includes at least feedback packet to report this to the sender that includes at least
the RTCP RR and the ECN feedback message. Thus speeding up the the RTCP RR and the ECN feedback message. Thus speeding up the
detection at the sender of the losses and thus triggering sender side detection at the sender of the losses and thus triggering sender side
mitigation. mitigation.
A sender that detects high packet loss rates for ECT-marked packets A sender that detects high packet loss rates for ECT-marked packets
SHOULD immediately switch to sender packets as not-ECT to determine SHOULD immediately switch to sending packets as not-ECT to determine
if the losses potentially are due to the ECT markings. If the losses if the losses potentially are due to the ECT markings. If the losses
disappear when the ECT-marking is discontinued, the RTP sender should disappear when the ECT-marking is discontinued, the RTP sender should
go back to initiation procedures to attempt to verify the apparent go back to initiation procedures to attempt to verify the apparent
loss of ECN capability of the used path. If a re-initiation fails loss of ECN capability of the used path. If a re-initiation fails
then the two possible actions exist: then the two possible actions exist:
1. Periodically retry the ECN initiation to detect if a path change 1. Periodically retry the ECN initiation to detect if a path change
occurs to a path that are ECN capable. occurs to a path that is ECN capable.
2. Renegotiating the session to disable ECN support. This is a 2. Renegotiating the session to disable ECN support. This is a
choice that is suitable if the impact of ECT probing on the media choice that is suitable if the impact of ECT probing on the media
quality are noticeable. If multiple initiations has been quality are noticeable. If multiple initiations has been
successful but the following full usage of ECN has resulted in successful but the following full usage of ECN has resulted in
the fallback procedures then disabling of the ECN support is the fallback procedures then disabling of the ECN support is
RECOMMENDED. RECOMMENDED.
We foresee the possibility of flapping ECN capability due to several We foresee the possibility of flapping ECN capability due to several
reasons: video switching MCU or similar middleboxes that selects to reasons: video switching MCU or similar middleboxes that selects to
skipping to change at page 28, line 43 skipping to change at page 28, line 51
of ECT marked packet sent. Two issues may cause a mismatch in these of ECT marked packet sent. Two issues may cause a mismatch in these
statistics: severe network congestion or unresponsive congestion statistics: severe network congestion or unresponsive congestion
control might cause some ECT-marked packets to be lost, and packet control might cause some ECT-marked packets to be lost, and packet
duplication might result in some packets being received, and counted duplication might result in some packets being received, and counted
in the statistics, multiple times (potentially with a different ECN- in the statistics, multiple times (potentially with a different ECN-
mark on each copy of the duplicate). mark on each copy of the duplicate).
The level of packet duplication included in the report can be The level of packet duplication included in the report can be
estimated from the sum over all of fields counting received packets estimated from the sum over all of fields counting received packets
compared to the number of packets sent. A high level of packet compared to the number of packets sent. A high level of packet
duplication increases the insecurity in the statistics and firm duplication increases the uncertainty in the statistics, making if
conclusions becomes more difficult and requires clearer statics. more difficult to draw firm conclusions about the behaviour of the
network. This issue is also present with standard RTCP reception
reports.
Detecting clearing of ECN field: If the ratio between ECT and not-ECT Detecting clearing of ECN field: If the ratio between ECT and not-ECT
transmitted in the reports has become all not-ECT or substantially transmitted in the reports has become all not-ECT or substantially
changed towards not-ECT then this is clearly indication that the path changed towards not-ECT then this is clearly indication that the path
results in clearing of the ECT field. results in clearing of the ECT field.
Dropping of ECT packets: To determine if the packet drop ratio is Dropping of ECT packets: To determine if the packet drop ratio is
different between not-ECT and ECT marked transmission requires a mix different between not-ECT and ECT marked transmission requires a mix
of transmitted traffic. The sender should compare if the delivery of transmitted traffic. The sender should compare if the delivery
percentage (delivered / transmitted) between ECT and not-ECT is percentage (delivered / transmitted) between ECT and not-ECT is
skipping to change at page 34, line 21 skipping to change at page 34, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin_seq | End_seq | | Begin_seq | End_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 | | chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BT: Block Type, the value identifying this block is [TBA1]. BT: Block Type, the value identifying this block is [TBA3].
R: Bits are reserved and MUST be set to 0 on transmission and MUST be R: Bits are reserved and MUST be set to 0 on transmission and MUST be
ignored on reception. ignored on reception.
Block Length: The block length of this full report block in 32-bit Block Length: The block length of this full report block in 32-bit
words minus one. The minimal report block size is 3, i.e. fixed words minus one. The minimal report block size is 3, i.e. fixed
parts (12 bytes) plus 2 chunks (4 bytes) expressed as 32-bit words parts (12 bytes) plus 2 chunks (4 bytes) expressed as 32-bit words
(3+1) minus 1. (3+1) minus 1.
SSRC of Media Sender SSRC of Media Sender that this report concerns SSRC of Media Sender SSRC of Media Sender that this report concerns
skipping to change at page 35, line 9 skipping to change at page 35, line 17
end_seq: Last RTP sequence number included in this report. end_seq: Last RTP sequence number included in this report.
chunk i: A chunk reporting on a part of bit-vector indicating if the chunk i: A chunk reporting on a part of bit-vector indicating if the
packet was excluded from the ECN Nonce due to being lost or ECN CE packet was excluded from the ECN Nonce due to being lost or ECN CE
marked. marked.
The Nonce sum initial value for a new media sender (new SSRC) SHALL The Nonce sum initial value for a new media sender (new SSRC) SHALL
be 00b. Otherwise the Initial value is the Nonce value calculated be 00b. Otherwise the Initial value is the Nonce value calculated
for the RTP packet with sequence number begin_seq -1. The initial for the RTP packet with sequence number begin_seq -1. The initial
value for the expressed reporting interval is included in the INV value for the expressed reporting interval is included in the INV
field. The receiver calculate the 2-bit Nonce XOR sum over all field. The receiver calculates the 2-bit Nonce XOR sum over all
received RTP packets in the reporting interval including the one with received RTP packets in the reporting interval including the one with
end_seq sequence number. We note that the RTCP participant doing the end_seq sequence number. We note that the RTCP participant doing the
Nonce sum MUST perform suppression of packet duplicates. The nonce Nonce sum MUST perform suppression of packet duplicates. The nonce
sum will become incorrect if any duplicates are included in the sum. sum will become incorrect if any duplicates are included in the sum.
All packets not received or received as ECN-CE marked when All packets not received or received as ECN-CE marked when
constructing the ECN Nonce report MUST be explicitly marked in the constructing the ECN Nonce report MUST be explicitly marked in the
bitvector. bitvector.
The Nonce reporting interval is RECOMMENDED to cover all the RTP The Nonce reporting interval is RECOMMENDED to cover all the RTP
packets received during the three last regular reporting intervals. packets received during the three last regular reporting intervals.
skipping to change at page 35, line 34 skipping to change at page 35, line 42
Two additional considerations must be made when selecting the Two additional considerations must be made when selecting the
reporting interval. First, are the MTU considerations. The packet reporting interval. First, are the MTU considerations. The packet
vector and its encoding into chunks results in a variable sized vector and its encoding into chunks results in a variable sized
report. The size depends on two main factors, the number of packets report. The size depends on two main factors, the number of packets
to report on and the frequency of bit-value changes in the vector. to report on and the frequency of bit-value changes in the vector.
The reporting interval may need to be shortened to two or even one The reporting interval may need to be shortened to two or even one
reporting interval if the resulting ECN nonce report becomes too big reporting interval if the resulting ECN nonce report becomes too big
to fit into the RTCP packet. to fit into the RTCP packet.
Secondly, the RTP sequence number can easily wrap and that needs to Secondly, the RTP sequence number can easily wrap and that needs to
be considered when they are handed. The report SHALL NOT report on be considered when they are handled. The report SHALL NOT report on
more than 32768 consecutive packets. The last sequence number is the more than 32768 consecutive packets. The last sequence number is the
extended sequence number that is equal too or smaller (less than extended sequence number that is equal too or smaller (less than
65535 packets) than the value present in the Receiver Reports 65535 packets) than the value present in the Receiver Reports
"extended highest sequence number received" field. The "first "extended highest sequence number received" field. The "first
sequence number" value is thus an extended sequence number which is sequence number" value is thus an extended sequence number which is
smaller than the "last sequence number". If there is a wrap between smaller than the "last sequence number". If there is a wrap between
the first sequence number and the last, i.e. if the first sequence the first sequence number and the last, i.e. if the first sequence
number is greater than the last sequence number (when seen as 16-bit number is greater than the last sequence number (when seen as 16-bit
unsigned integers), this needs to included in the calculation. If an unsigned integers), this needs to included in the calculation. If an
application is having these issues, the frequency of regular RTCP application is having these issues, the frequency of the regular RTCP
reporting should be modified by ensuring that the application chooses reporting should be modified by ensuring that the application chooses
appropriate settings for the minimum RTCP reporting interval appropriate settings for the minimum RTCP reporting interval
parameters. parameters.
Both the ECN-CE and packet loss information is structured as bit Both the ECN-CE and packet loss information is structured as bit
vectors where the first bit represents the RTP packet with the vectors where the first bit represents the RTP packet with the
sequence number equal to the First Sequence number. The bit-vector sequence number equal to the First Sequence number. The bit-vector
will contain values representing all packets up to and including the will contain values representing all packets up to and including the
one in the "end_seq" field. The chunk mechanism used to represent one in the "end_seq" field. The chunk mechanism used to represent
the bit-vector in an efficient way may appear longer upon reception the bit-vector in an efficient way may appear longer upon reception
skipping to change at page 41, line 27 skipping to change at page 41, line 43
10. Examples of SDP Signalling 10. Examples of SDP Signalling
(tbd) (tbd)
11. Open Issues 11. Open Issues
As this draft is under development some known open issues exist and As this draft is under development some known open issues exist and
are collected here. Please consider them and provide input. are collected here. Please consider them and provide input.
1. Packet duplication. Packet duplication results in uncertainties 1. The negotiation and directionality attribute is going to need
in the ECN summary counters. At the same time suppressing
duplicates and ignoring their ECN marks may also be problematic.
Consider the case when a packet get duplicated prior to a
congestion point and one version arrives with a ECT mark, and the
other with CE mark. What to report?
2. The negotiation and directionality attribute is going to need
some consideration for multi-party sessions when readonly some consideration for multi-party sessions when readonly
capability might be sufficient to enable ECN for all incomming capability might be sufficient to enable ECN for all incoming
streams. However, it would beneficial to know if no potential streams. However, it would beneficial to know if no potential
sender support setting ECN. sender support setting ECN.
3. Consider initiation optimizations that allows for multi SSRC 2. Consider initiation optimizations that allows for multi SSRC
sender nodes to still have rapid usage of ECN. sender nodes to still have rapid usage of ECN.
4. Feedback suppression for ECN-CE, both for groups, and in case an 3. Feedback suppression for ECN-CE, both for groups, and in case an
additional CE mark arrives within a RTT at the receiver. additional CE mark arrives within a RTT at the receiver.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
skipping to change at page 42, line 34 skipping to change at page 42, line 40
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008. RFC 5348, September 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
12.2. Informative References 12.2. Informative References
[I-D.ietf-avt-rtcpssm]
Ott, J. and J. Chesterfield, "RTCP Extensions for Single-
Source Multicast Sessions with Unicast Feedback",
draft-ietf-avt-rtcpssm-19 (work in progress),
November 2009.
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-tsvwg-ecn-tunnel] [I-D.ietf-tsvwg-ecn-tunnel]
Briscoe, B., "Tunnelling of Explicit Congestion Briscoe, B., "Tunnelling of Explicit Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-07 (work in Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in
progress), February 2010. progress), March 2010.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Secure RTP", Path Key Agreement for Secure RTP",
draft-zimmermann-avt-zrtp-17 (work in progress), draft-zimmermann-avt-zrtp-17 (work in progress),
January 2010. January 2010.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
skipping to change at page 44, line 21 skipping to change at page 44, line 21
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009. Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. 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.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 35 change blocks. 
90 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/