draft-ietf-avtcore-multi-media-rtp-session-09.txt   draft-ietf-avtcore-multi-media-rtp-session-10.txt 
AVTCORE WG M. Westerlund AVTCORE WG M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3550, 3551 (if approved) C. Perkins Updates: 3550, 3551 (if approved) C. Perkins
Intended status: Standards Track University of Glasgow Intended status: Standards Track University of Glasgow
Expires: January 21, 2016 J. Lennox Expires: March 18, 2016 J. Lennox
Vidyo Vidyo
July 20, 2015 September 15, 2015
Sending Multiple Types of Media in a Single RTP Session Sending Multiple Types of Media in a Single RTP Session
draft-ietf-avtcore-multi-media-rtp-session-09 draft-ietf-avtcore-multi-media-rtp-session-10
Abstract Abstract
This document specifies how an RTP session can contain RTP Streams This document specifies how an RTP session can contain RTP Streams
with media from multiple media types such as audio, video, and text. with media from multiple media types such as audio, video, and text.
This has been restricted by the RTP Specification, and thus this This has been restricted by the RTP Specification, and thus this
document updates RFC 3550 and RFC 3551 to enable this behaviour for document updates RFC 3550 and RFC 3551 to enable this behaviour for
applications that satisfy the applicability for using multiple media applications that satisfy the applicability for using multiple media
types in a single RTP session. types in a single RTP session.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 21, 2016. This Internet-Draft will expire on March 18, 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 2, line 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background and Motivation . . . . . . . . . . . . . . . . . . 3 3. Background and Motivation . . . . . . . . . . . . . . . . . . 3
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Using Multiple Media Types in a Single RTP Session . . . . . 6 5. Using Multiple Media Types in a Single RTP Session . . . . . 6
5.1. Allowing Multiple Media Types in an RTP Session . . . . . 6 5.1. Allowing Multiple Media Types in an RTP Session . . . . . 6
5.2. Demultiplexing media types within an RTP session . . . . 7 5.2. Demultiplexing media types within an RTP session . . . . 7
5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8 5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8
5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8
6. Extension Considerations . . . . . . . . . . . . . . . . . . 8 6. Extension Considerations . . . . . . . . . . . . . . . . . . 9
6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9 6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9
6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 10 6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 10
6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11 6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11
7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Real-time Transport Protocol [RFC3550] was designed to use The Real-time Transport Protocol [RFC3550] was designed to use
separate RTP sessions to transport different types of media. This separate RTP sessions to transport different types of media. This
implies that different transport layer flows are used for different implies that different transport layer flows are used for different
media streams. For example, a video conferencing application might media streams. For example, a video conferencing application might
send audio and video traffic RTP flows on separate UDP ports. With send audio and video traffic RTP flows on separate UDP ports. With
increased use of network address/port translation, firewalls, and increased use of network address/port translation, firewalls, and
other middleboxes it is, however, becoming difficult to establish other middleboxes it is, however, becoming difficult to establish
skipping to change at page 3, line 27 skipping to change at page 3, line 27
2. Terminology 2. Terminology
The terms Encoded Stream, Endpoint, Media Source, RTP Session, and The terms Encoded Stream, Endpoint, Media Source, RTP Session, and
RTP Stream are used as defined in RTP Stream are used as defined in
[I-D.ietf-avtext-rtp-grouping-taxonomy]. We also define the [I-D.ietf-avtext-rtp-grouping-taxonomy]. We also define the
following terms: following terms:
Media Type: The general type of media data used by a real-time Media Type: The general type of media data used by a real-time
application. The media type corresponds to the value used in the application. The media type corresponds to the value used in the
<media> field of an SDP m= line. The media types defined at the <media> field of an SDP m= line. The media types defined at the
time of this writing are "audio", "video", "text", "application", time of this writing are "audio", "video", "text", "image",
and "message". "application", and "message". [RFC4566] [RFC6466]
Quality of Service (QoS): Network mechanisms that are intended to Quality of Service (QoS): Network mechanisms that are intended to
ensure that the packets within a flow or with a specific marking ensure that the packets within a flow or with a specific marking
are transported with certain properties. are transported with certain properties.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Background and Motivation 3. Background and Motivation
skipping to change at page 10, line 9 skipping to change at page 10, line 13
the source streams. the source streams.
An example SDP fragment showing the grouping structures is provided An example SDP fragment showing the grouping structures is provided
in Figure 1. This example is not legal SDP and only the most in Figure 1. This example is not legal SDP and only the most
important attributes have been left in place. Note that this SDP is important attributes have been left in place. Note that this SDP is
not an initial BUNDLE offer. As can be seen there are two bundle not an initial BUNDLE offer. As can be seen there are two bundle
groups, one for the source RTP session and one for the groups, one for the source RTP session and one for the
retransmissions. Then each of the media sources are grouped with its retransmissions. Then each of the media sources are grouped with its
retransmission flow using FID, resulting in three more groupings. retransmission flow using FID, resulting in three more groupings.
a=group:BUNDLE foo bar fiz a=group:BUNDLE foo bar fiz
a=group:BUNDLE zoo kelp glo a=group:BUNDLE zoo kelp glo
a=group:FID foo zoo a=group:FID foo zoo
a=group:FID bar kelp a=group:FID bar kelp
a=group:FID fiz glo a=group:FID fiz glo
m=audio 10000 RTP/AVP 0 m=audio 10000 RTP/AVP 0
a=mid:foo a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 10000 RTP/AVP 31 m=video 10000 RTP/AVP 31
a=mid:bar a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
m=video 10000 RTP/AVP 31 m=video 10000 RTP/AVP 31
a=mid:fiz a=mid:fiz
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
m=audio 40000 RTP/AVPF 99 m=audio 40000 RTP/AVPF 99
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=fmtp:99 apt=0;rtx-time=3000 a=fmtp:99 apt=0;rtx-time=3000
a=mid:zoo a=mid:zoo
m=video 40000 RTP/AVPF 100 m=video 40000 RTP/AVPF 100
a=rtpmap:100 rtx/90000 a=rtpmap:100 rtx/90000
a=fmtp:199 apt=31;rtx-time=3000 a=fmtp:199 apt=31;rtx-time=3000
a=mid:kelp a=mid:kelp
m=video 40000 RTP/AVPF 100 m=video 40000 RTP/AVPF 100
a=rtpmap:100 rtx/90000 a=rtpmap:100 rtx/90000
a=fmtp:199 apt=31;rtx-time=3000 a=fmtp:199 apt=31;rtx-time=3000
a=mid:glo a=mid:glo
Figure 1: SDP example of Session Multiplexed RTP Retransmission Figure 1: SDP example of Session Multiplexed RTP Retransmission
6.2. RTP Payload Format for Generic FEC 6.2. RTP Payload Format for Generic FEC
The RTP Payload Format for Generic Forward Error Correction (FEC) The RTP Payload Format for Generic Forward Error Correction (FEC)
[RFC5109] (and its predecessor [RFC2733]) can either send the FEC [RFC5109] (and its predecessor [RFC2733]) can either send the FEC
stream as a separate RTP stream, or it can send the FEC combined with stream as a separate RTP stream, or it can send the FEC combined with
the original RTP stream as a redundant encoding [RFC2198]. the original RTP stream as a redundant encoding [RFC2198].
skipping to change at page 13, line 4 skipping to change at page 13, line 6
Sending multiple media types in a single RTP session will generally Sending multiple media types in a single RTP session will generally
require that all use the same security mechanism, whereas media sent require that all use the same security mechanism, whereas media sent
using different RTP sessions can be secured in different ways. When using different RTP sessions can be secured in different ways. When
different media types have different security requirements, it might different media types have different security requirements, it might
be necessary to send them using separate RTP sessions to meet those be necessary to send them using separate RTP sessions to meet those
different requirements. This can have significant costs in terms of different requirements. This can have significant costs in terms of
resource usage, session set-up time, etc. resource usage, session set-up time, etc.
9. IANA Considerations 9. IANA Considerations
This memo makes no request of IANA. This memo makes no request of IANA.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Christer Holmberg, Gunnar Hellstroem, The authors would like to thank Christer Holmberg, Gunnar Hellstroem,
and Charles Eckel for the feedback on the document. Charles Eckel, and Tolga Asveren for their feedback on the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
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",
draft-ietf-avtcore-rtp-multi-stream-08 (work in progress), draft-ietf-avtcore-rtp-multi-stream-08 (work in progress),
July 2015. July 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.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[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,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>. <http://www.rfc-editor.org/info/rfc3551>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-avtcore-multiplex-guidelines] [I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand, Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to "Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore- Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-03 (work in progress), October 2014. multiplex-guidelines-03 (work in progress), October 2014.
[I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-10 (work in progress),
July 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-07 (work in progress), June avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015. 2015.
[I-D.ietf-dart-dscp-rtp] [I-D.ietf-dart-dscp-rtp]
Black, D. and P. Jones, "Differentiated Services Black, D. and P. Jones, "Differentiated Services
(DiffServ) and Real-time Communication", draft-ietf-dart- (DiffServ) and Real-time Communication", draft-ietf-dart-
dscp-rtp-10 (work in progress), November 2014. dscp-rtp-10 (work in progress), November 2014.
[I-D.lennox-payload-ulp-ssrc-mux] [I-D.lennox-payload-ulp-ssrc-mux]
Lennox, J., "Supporting Source-Multiplexing of the Real- Lennox, J., "Supporting Source-Multiplexing of the Real-
Time Transport Protocol (RTP) Payload for Generic Forward Time Transport Protocol (RTP) Payload for Generic Forward
Error Correction", draft-lennox-payload-ulp-ssrc-mux-00 Error Correction", draft-lennox-payload-ulp-ssrc-mux-00
(work in progress), February 2013. (work in progress), February 2013.
[I-D.westerlund-avtcore-transport-multiplexing]
Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP
Sessions onto a Single Lower-Layer Transport", draft-
westerlund-avtcore-transport-multiplexing-07 (work in
progress), October 2013.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
DOI 10.17487/RFC2198, September 1997, DOI 10.17487/RFC2198, September 1997,
<http://www.rfc-editor.org/info/rfc2198>. <http://www.rfc-editor.org/info/rfc2198>.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733, DOI for Generic Forward Error Correction", RFC 2733,
10.17487/RFC2733, December 1999, DOI 10.17487/RFC2733, December 1999,
<http://www.rfc-editor.org/info/rfc2733>. <http://www.rfc-editor.org/info/rfc2733>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[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,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>. <http://www.rfc-editor.org/info/rfc4588>.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, DOI 10.17487/ Session Description Protocol", RFC 4756,
RFC4756, November 2006, DOI 10.17487/RFC4756, November 2006,
<http://www.rfc-editor.org/info/rfc4756>. <http://www.rfc-editor.org/info/rfc4756>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>. 2007, <http://www.rfc-editor.org/info/rfc5109>.
[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, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>. <http://www.rfc-editor.org/info/rfc5576>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, DOI 10.17487/
RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487 Protocol (SDP) Grouping Framework", RFC 5888,
/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <http://www.rfc-editor.org/info/rfc5888>.
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
the Session Description Protocol", RFC 5956, DOI 10.17487/ the Session Description Protocol", RFC 5956,
RFC5956, September 2010, DOI 10.17487/RFC5956, September 2010,
<http://www.rfc-editor.org/info/rfc5956>. <http://www.rfc-editor.org/info/rfc5956>.
[RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media
Type for the Session Description Protocol (SDP)",
RFC 6466, DOI 10.17487/RFC6466, December 2011,
<http://www.rfc-editor.org/info/rfc6466>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/ Clock Rates in an RTP Session", RFC 7160,
RFC7160, April 2014, DOI 10.17487/RFC7160, April 2014,
<http://www.rfc-editor.org/info/rfc7160>. <http://www.rfc-editor.org/info/rfc7160>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <http://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <http://www.rfc-editor.org/info/rfc7202>. 2014, <http://www.rfc-editor.org/info/rfc7202>.
 End of changes. 24 change blocks. 
67 lines changed or deleted 57 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/