draft-ietf-avtcore-rtp-multi-stream-08.txt   draft-ietf-avtcore-rtp-multi-stream-09.txt 
AVTCORE J. Lennox AVTCORE J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Updates: 3550, 4585 (if approved) M. Westerlund Updates: 3550, 4585 (if approved) M. Westerlund
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 7, 2016 Q. Wu Expires: April 2, 2016 Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
July 6, 2015 September 30, 2015
Sending Multiple Media Streams in a Single RTP Session Sending Multiple Media Streams in a Single RTP Session
draft-ietf-avtcore-rtp-multi-stream-08 draft-ietf-avtcore-rtp-multi-stream-09
Abstract Abstract
This memo expands and clarifies the behaviour of Real-time Transport This memo expands and clarifies the behaviour of Real-time Transport
Protocol (RTP) endpoints that use multiple synchronization sources Protocol (RTP) endpoints that use multiple synchronization sources
(SSRCs). This occurs, for example, when an endpoint sends multiple (SSRCs). This occurs, for example, when an endpoint sends multiple
media streams in a single RTP session. This memo updates RFC 3550 media streams in a single RTP session. This memo updates RFC 3550
with regards to handling multiple SSRCs per endpoint in RTP sessions, with regards to handling multiple SSRCs per endpoint in RTP sessions,
with a particular focus on RTCP behaviour. It also updates RFC 4585 with a particular focus on RTCP behaviour. It also updates RFC 4585
to update and clarify the calculation of the timeout of SSRCs and the to update and clarify the calculation of the timeout of SSRCs and the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 7, 2016. This Internet-Draft will expire on April 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 5, line 11 skipping to change at page 5, line 11
data. Similarly, some layered media encoding schemes, for example data. Similarly, some layered media encoding schemes, for example
H.264 SVC [RFC6190], can be used in a configuration where each layer H.264 SVC [RFC6190], can be used in a configuration where each layer
is sent using a different SSRC within a single RTP session. is sent using a different SSRC within a single RTP session.
4. Use of RTP by endpoints that send multiple media streams 4. Use of RTP by endpoints that send multiple media streams
RTP is inherently a group communication protocol. Each endpoint in RTP is inherently a group communication protocol. Each endpoint in
an RTP session will use one or more SSRCs, as will some types of RTP an RTP session will use one or more SSRCs, as will some types of RTP
level middlebox. Accordingly, unless restrictions on the number of level middlebox. Accordingly, unless restrictions on the number of
SSRCs have been signalled, RTP endpoints can expect to receive RTP SSRCs have been signalled, RTP endpoints can expect to receive RTP
data packets sent using with a number of different SSRCs, within a data packets sent using a number of different SSRCs, within a single
single RTP session. This can occur irrespective of whether the RTP RTP session. This can occur irrespective of whether the RTP session
session is running over a point-to-point connection or a multicast is running over a point-to-point connection or a multicast group,
group, since middleboxes can be used to connect multiple transport since middleboxes can be used to connect multiple transport
connections together into a single RTP session (the RTP session is connections together into a single RTP session (the RTP session is
defined by the shared SSRC space, not by the transport connections). defined by the shared SSRC space, not by the transport connections).
Furthermore, if RTP mixers are used, some SSRCs might only be visible Furthermore, if RTP mixers are used, some SSRCs might only be visible
in the contributing source (CSRC) list of an RTP packet and in RTCP, in the contributing source (CSRC) list of an RTP packet and in RTCP,
and might not appear directly as the SSRC of an RTP data packet. and might not appear directly as the SSRC of an RTP data packet.
Every RTP endpoint will have an allocated share of the available Every RTP endpoint will have an allocated share of the available
session bandwidth, as determined by signalling and congestion session bandwidth, as determined by signalling and congestion
control. The endpoint MUST keep its total media sending rate within control. The endpoint MUST keep its total media sending rate within
this share. However, endpoints that send multiple media streams do this share. However, endpoints that send multiple media streams do
skipping to change at page 8, line 43 skipping to change at page 8, line 43
aggregate reports from many SSRCs. A 1500 octet MTU can fit five aggregate reports from many SSRCs. A 1500 octet MTU can fit five
typical size reports into a compound RTCP packet, so this is a real typical size reports into a compound RTCP packet, so this is a real
concern if endpoints aggregate RTCP reports from multiple SSRCs. concern if endpoints aggregate RTCP reports from multiple SSRCs.
The issue raised in the previous paragraph is mitigated by the The issue raised in the previous paragraph is mitigated by the
modification in timeout behaviour specified in Section 7.1.2 of this modification in timeout behaviour specified in Section 7.1.2 of this
memo. This mitigation is in place in those cases where the RTCP memo. This mitigation is in place in those cases where the RTCP
bandwidth is sufficiently high that an endpoint, using avg_rtcp_size bandwidth is sufficiently high that an endpoint, using avg_rtcp_size
calculated without taking into account the number of reporting SSRCs, calculated without taking into account the number of reporting SSRCs,
can transmit more frequently than approximately every 5 seconds. can transmit more frequently than approximately every 5 seconds.
Note, however, that the non-modified endpoint's RTCP reporting is Note, however, that the non-updated endpoint's RTCP reporting is
still negatively impacted even if the premature timeout of its SSRCs still negatively impacted even if the premature timeout of its SSRCs
are avoided. If compatibility with non-updated endpoints is a are avoided. If compatibility with non-updated endpoints is a
concern, the number of reports from different SSRCs aggregated into a concern, the number of reports from different SSRCs aggregated into a
single compound RTCP packet SHOULD either be limited to two reports, single compound RTCP packet SHOULD either be limited to two reports,
or aggregation ought not used at all. This will limit the non- or aggregation ought not used at all. This will limit the non-
updated endpoint's RTCP reporting interval to be no larger than twice updated endpoint's RTCP reporting interval to be no larger than twice
the RTCP reporting interval that would be chosen by an endpoint the RTCP reporting interval that would be chosen by an endpoint
following this specification. following this specification.
5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs 5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs
skipping to change at page 9, line 18 skipping to change at page 9, line 18
of [RFC3550], and in Section 3.5.3 of [RFC4585] if the RTP/AVPF of [RFC3550], and in Section 3.5.3 of [RFC4585] if the RTP/AVPF
profile or the RTP/SAVPF profile is used, regarding actions to take profile or the RTP/SAVPF profile is used, regarding actions to take
when scheduling and sending RTCP packets where multiple reporting when scheduling and sending RTCP packets where multiple reporting
SSRCs are aggregating their RTCP packets into the same compound RTCP SSRCs are aggregating their RTCP packets into the same compound RTCP
packet. These changes to the RTCP scheduling rules are needed to packet. These changes to the RTCP scheduling rules are needed to
maintain important RTCP timing properties, including the inter-packet maintain important RTCP timing properties, including the inter-packet
distribution, and the behaviour during flash joins and other changes distribution, and the behaviour during flash joins and other changes
in session membership. in session membership.
The variables tn, tp, tc, T, and Td used in the following are defined The variables tn, tp, tc, T, and Td used in the following are defined
in Section 6.3 of [RFC3550]. The variable T_rr_last is defined in in Section 6.3 of [RFC3550]. The variables T_rr_interval and
[RFC4585]. T_rr_last are defined in [RFC4585].
Each endpoint MUST schedule RTCP transmission independently for each Each endpoint MUST schedule RTCP transmission independently for each
of its SSRCs using the regular calculation of tn for the RTP profile of its SSRCs using the regular calculation of tn for the RTP profile
being used. Each time the timer tn expires for an SSRC, the endpoint being used. Each time the timer tn expires for an SSRC, the endpoint
MUST perform RTCP timer reconsideration and, if applicable, T_rr_int MUST perform RTCP timer reconsideration and, if applicable,
based suppression. If the result indicates that a compound RTCP T_rr_interval based suppression. If the result indicates that a
packet is to be sent by that SSRC, and the transmission is not an compound RTCP packet is to be sent by that SSRC, and the transmission
early RTCP packet [RFC4585], then the endpoint SHOULD try to is not an early RTCP packet [RFC4585], then the endpoint SHOULD try
aggregate RTCP packets of additional SSRCs that are scheduled in the to aggregate RTCP packets of additional SSRCs that are scheduled in
future into the compound RTCP packet before it is sent. The reason the future into the compound RTCP packet before it is sent. The
to limit or not aggregate at due to backwards compatibility reasons reason to limit or not aggregate at due to backwards compatibility
was discussed earlier in Section 5.3.1. reasons was discussed earlier in Section 5.3.1.
Aggregation proceeds as follows. The endpoint selects the SSRC that Aggregation proceeds as follows. The endpoint selects the SSRC that
has the smallest tn value after the current time, tc, and prepares has the smallest tn value after the current time, tc, and prepares
the RTCP packets that SSRC would send if its timer tn expired at tc. the RTCP packets that SSRC would send if its timer tn expired at tc.
If those RTCP packets will fit into the compound RTCP packet that is If those RTCP packets will fit into the compound RTCP packet that is
being generated, taking into account the path MTU and the previously being generated, taking into account the path MTU and the previously
added RTCP packets, then they are added to the compound RTCP packet; added RTCP packets, then they are added to the compound RTCP packet;
otherwise they are discarded. This process is repeated for each otherwise they are discarded. This process is repeated for each
SSRC, in order of increasing tn, until the compound RTCP packet is SSRC, in order of increasing tn, until the compound RTCP packet is
full, or all SSRCs have been aggregated. At that point, the compound full, or all SSRCs have been aggregated. At that point, the compound
skipping to change at page 10, line 9 skipping to change at page 10, line 9
a. For the first SSRC that reported in the compound RTCP packet, set a. For the first SSRC that reported in the compound RTCP packet, set
the effective transmission time, tt, of that SSRC to tc. the effective transmission time, tt, of that SSRC to tc.
b. For each additional SSRC that reported in the compound RTCP b. For each additional SSRC that reported in the compound RTCP
packet, calculate the transmission time that SSRC would have had packet, calculate the transmission time that SSRC would have had
if it had not been aggregated into the compound RTCP packet. if it had not been aggregated into the compound RTCP packet.
This is derived by taking tn for that SSRC, then performing This is derived by taking tn for that SSRC, then performing
reconsideration and updating tn until tp + T <= tn. Once this is reconsideration and updating tn until tp + T <= tn. Once this is
done, set the effective transmission time, tt, for that SSRC to done, set the effective transmission time, tt, for that SSRC to
the calculated value of tn. If the RTP/AVPF profile or the RTP/ the calculated value of tn. If the RTP/AVPF profile or the RTP/
SAVPF profile is being used, then T_rr_int based suppression MUST SAVPF profile is being used, then T_rr_interval based suppression
NOT be used in this calculation. MUST NOT be used in this calculation.
c. Calculate average effective transmission time, tt_avg, for the c. Calculate average effective transmission time, tt_avg, for the
compound RTCP packet based on the tt values for all SSRCs sent in compound RTCP packet based on the tt values for all SSRCs sent in
the compound RTCP packet. Set tp for each of the SSRCs sent in the compound RTCP packet. Set tp for each of the SSRCs sent in
the compound RTCP packet to tt_avg. If the RTP/AVPF profile or the compound RTCP packet to tt_avg. If the RTP/AVPF profile or
the RTP/SAVPF profile is being used, set T_tt_last for each SSRC the RTP/SAVPF profile is being used, set T_tt_last for each SSRC
sent in the compound RTCP packet to tt_avg. sent in the compound RTCP packet to tt_avg.
d. For each of the SSRCs sent in the compound RTCP packet, calculate d. For each of the SSRCs sent in the compound RTCP packet, calculate
new tn values based on the updated parameters and the usual RTCP new tn values based on the updated parameters and the usual RTCP
skipping to change at page 10, line 37 skipping to change at page 10, line 37
If T_rr_interval == 0, or if T_rr_interval != 0 and option 1, 2a, or If T_rr_interval == 0, or if T_rr_interval != 0 and option 1, 2a, or
2b of the algorithm are chosen, then the above mechanism updates the 2b of the algorithm are chosen, then the above mechanism updates the
necessary variables. However, if the transmission is suppressed per necessary variables. However, if the transmission is suppressed per
option 2c of the algorithm, then tp is updated to tc as aggregation option 2c of the algorithm, then tp is updated to tc as aggregation
has not taken place. has not taken place.
Reverse reconsideration MUST be performed following Section 6.3.4 of Reverse reconsideration MUST be performed following Section 6.3.4 of
[RFC3550]. In some cases, this can lead to the value of tp after [RFC3550]. In some cases, this can lead to the value of tp after
reverse reconsideration being larger than tc. This is not a problem, reverse reconsideration being larger than tc. This is not a problem,
and has the desired effect of proportionally pulling the tp value and has the desired effect of proportionally pulling the tp value
towards tc (as well as tn) as the group size shrinks in direct towards tc (as well as tn) as the reporting interval shrinks in
proportion the reduced group size. direct proportion the reduced group size.
The above algorithm has been shown in simulations to maintain the The above algorithm has been shown in simulations to maintain the
inter-RTCP packet transmission time distribution for each SSRC, and inter-RTCP packet transmission time distribution for each SSRC, and
to consume the same amount of bandwidth as non-aggregated RTCP to consume the same amount of bandwidth as non-aggregated RTCP
packets. With this algorithm the actual transmission interval for an packets. With this algorithm the actual transmission interval for an
SSRC triggering an RTCP compound packet transmission is following the SSRC triggering an RTCP compound packet transmission is following the
regular transmission rules. The value tp is set to somewhere in the regular transmission rules. The value tp is set to somewhere in the
interval [0,1.5/1.21828*Td] ahead of tc. The actual value is average interval [0,1.5/1.21828*Td] ahead of tc. The actual value is average
of one instance of tc and the randomized transmission times of the of one instance of tc and the randomized transmission times of the
additional SSRCs, thus the lower range of the interval is more additional SSRCs, thus the lower range of the interval is more
skipping to change at page 12, line 26 skipping to change at page 12, line 26
o If separate SSRCs are used to send and receive media, then the o If separate SSRCs are used to send and receive media, then the
corresponding SSRC SHOULD be used for feedback, since they have corresponding SSRC SHOULD be used for feedback, since they have
differing RTCP bandwidth fractions. This can also affect the differing RTCP bandwidth fractions. This can also affect the
consideration if the SSRC can be used in immediate mode or not. consideration if the SSRC can be used in immediate mode or not.
o Some RTCP feedback packet types require consistency in the SSRC o Some RTCP feedback packet types require consistency in the SSRC
used. For example, if a TMMBR limitation [RFC5104] is set by an used. For example, if a TMMBR limitation [RFC5104] is set by an
SSRC, the same SSRC needs to be used to remove the limitation. SSRC, the same SSRC needs to be used to remove the limitation.
o If several SSRCs are suitable for sending feedback, if might be o If several SSRCs are suitable for sending feedback, it might be
desirable to use an SSRC that allows the sending of feedback as an desirable to use an SSRC that allows the sending of feedback as an
early RTCP packet. early RTCP packet.
When an RTCP feedback packet is sent as part of a compound RTCP When an RTCP feedback packet is sent as part of a compound RTCP
packet that aggregates reports from multiple SSRCs, there is no packet that aggregates reports from multiple SSRCs, there is no
requirement that the compound packet contains an SR or RR packet requirement that the compound packet contains an SR or RR packet
generated by the sender of the RTCP feedback packet. For reduced- generated by the sender of the RTCP feedback packet. For reduced-
size RTCP packets, aggregation of RTCP feedback packets from multiple size RTCP packets, aggregation of RTCP feedback packets from multiple
sources is not limited further than Section 4.2.2 of [RFC5506]. sources is not limited further than Section 4.2.2 of [RFC5506].
skipping to change at page 24, line 34 skipping to change at page 24, line 34
10. Acknowledgments 10. Acknowledgments
The authors like to thank Harald Alvestrand and everyone else who has The authors like to thank Harald Alvestrand and everyone else who has
been involved in the development of this document. been involved in the development of this document.
11. References 11. References
11.1. Normative References 11.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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
2006. DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Sending Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", draft- Multiple Types of Media in a Single RTP Session", draft-
ietf-avtcore-multi-media-rtp-session-07 (work in ietf-avtcore-multi-media-rtp-session-10 (work in
progress), March 2015. progress), September 2015.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session: "Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-06 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-06 (work
in progress), July 2015. in progress), July 2015.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-10 (work in progress), ietf-avtcore-rtp-topologies-update-10 (work in progress),
July 2015. July 2015.
[I-D.ietf-clue-framework] [I-D.ietf-clue-framework]
Duckworth, M., Pepperell, A., and S. Wenger, "Framework Duckworth, M., Pepperell, A., and S. Wenger, "Framework
for Telepresence Multi-Streams", draft-ietf-clue- for Telepresence Multi-Streams", draft-ietf-clue-
framework-22 (work in progress), April 2015. framework-23 (work in progress), September 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-22 (work in progress), June 2015. negotiation-23 (work in progress), July 2015.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC Modifiers for RTP Control Protocol (RTCP) Bandwidth",
3556, July 2003. RFC 3556, DOI 10.17487/RFC3556, July 2003,
<http://www.rfc-editor.org/info/rfc3556>.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. DOI 10.17487/RFC3830, August 2004,
<http://www.rfc-editor.org/info/rfc3830>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190, "RTP Payload Format for Scalable Video Coding", RFC 6190,
May 2011. DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, April 2014. Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014,
<http://www.rfc-editor.org/info/rfc7160>.
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
Seventh Floor Seventh Floor
Hackensack, NJ 07601 Hackensack, NJ 07601
USA USA
Email: jonathan@vidyo.com Email: jonathan@vidyo.com
Magnus Westerlund Magnus Westerlund
skipping to change at page 26, line 41 skipping to change at page 27, line 15
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
Seventh Floor Seventh Floor
Hackensack, NJ 07601 Hackensack, NJ 07601
USA USA
Email: jonathan@vidyo.com Email: jonathan@vidyo.com
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 2
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
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: sunseawq@huawei.com Email: sunseawq@huawei.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
 End of changes. 32 change blocks. 
48 lines changed or deleted 65 lines changed or added

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