draft-ietf-rtcweb-video-00.txt   draft-ietf-rtcweb-video-01.txt 
Network Working Group A.B. Roach Network Working Group A.B. Roach
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track July 01, 2014 Intended status: Standards Track October 27, 2014
Expires: January 02, 2015 Expires: April 30, 2015
WebRTC Video Processing and Codec Requirements WebRTC Video Processing and Codec Requirements
draft-ietf-rtcweb-video-00 draft-ietf-rtcweb-video-01
Abstract Abstract
This specification provides the requirements and consideration for This specification provides the requirements and considerations for
WebRTC applications to send and receive video across a network. It WebRTC applications to send and receive video across a network. It
specifies the video processing that is required, codecs and their specifies the video processing that is required, as well as video
parameters, and types of RTP packetization that need to be supported. codecs and their parameters.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 02, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Pre and Post Processing . . . . . . . . . . . . . . . . . . . 2 3. Pre and Post Processing . . . . . . . . . . . . . . . . . . . 2
3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3 3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3
3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3 3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3
4. Codec Considerations . . . . . . . . . . . . . . . . . . . . 3 4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 4
4.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Codec-Specific Considerations . . . . . . . . . . . . . . . . 4
4.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. VP9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. H.265 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Mandatory to Implement Video Codec . . . . . . . . . . . . . 6
5. Dealing with Packet Loss . . . . . . . . . . . . . . . . . . 4 6.1. Temperature of Working Group . . . . . . . . . . . . . . 6
6. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. Temperature of Working Group . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
One of the major functions of WebRTC endpoints is the ability to send One of the major functions of WebRTC endpoints is the ability to send
and receive interactive video. The video might come from a camera, a and receive interactive video. The video might come from a camera, a
screen recording, a stored file, or some other source. This screen recording, a stored file, or some other source. This
specification defines how the video is used and discusses special specification defines how the video is used and discusses special
considerations for processing the video. It also covers the video- considerations for processing the video. It also covers the video-
related algorithms WebRTC devices need to support. related algorithms WebRTC devices need to support.
Note that this document only discusses those issues dealing with
video codec handling. Issues that are related to transport of media
streams across the network are specified in
[I-D.ietf-rtcweb-rtp-usage].
2. Terminology 2. Terminology
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. Pre and Post Processing 3. Pre and Post Processing
This section provides guidance on pre- or post-processing of video This section provides guidance on pre- or post-processing of video
streams. streams.
Unless specified otherwise by the SDP or Codec, the color space Unless specified otherwise by the SDP or codec, the color space
SHOULD be TBD. SHOULD be sRGB [SRGB].
TODO: What color space is our default? TODO: I'm just throwing this out there to see if a specific proposal,
even if wrong, might draw more comment than "TBD". If you don't like
sRGB for this purpose, comment on the rtcweb@ietf.org mailing list.
It has been suggested that the MPEG "Coding independent media
description code points" specification [IEC23001-8] may have
applicability here.
3.1. Camera Source Video 3.1. Camera Source Video
To support a quality experience with no application level adjustment This document imposes no normative requirements on camera capture;
from the Javascript running in the browsers, WebRTC endpoints are however, implementors are encouraged to take advantage of the
REQUIRED to support: following features, if feasible for their platform:
o Automatic focus, if applicable for the camera in use o Automatic focus, if applicable for the camera in use
o Automatic white balance o Automatic white balance
o Automatic light level control o Automatic light level control
TODO: What other processing should be specified here?
3.2. Screen Source Video 3.2. Screen Source Video
If the video source is some portion of a computer screen (e.g., If the video source is some portion of a computer screen (e.g.,
desktop or application sharing), then the considerations in this desktop or application sharing), then the considerations in this
section also apply. section also apply.
TODO: What do we need to specify here? Because screen-sourced video can change resolution (due to, e.g.,
window resizing and similar operations), WebRTC video recipients MUST
be prepared to handle mid-stream resolution changes in a way that
preserves their utility. Precise handling (e.g., resizing the
element a video is rendered in versus scaling down the received
stream; decisions around letter/pillarboxing) is left to the
discretion of the application.
4. Codec Considerations Additionally, attention is drawn to the requirements in
[I-D.ietf-rtcweb-security-arch] section 5.2 and the considerations in
[I-D.ietf-rtcweb-security] section 4.1.1.
WebRTC endpoints are not required to support all the codecs in this TODO: Do we want to define additional metadata to indicate whether a
section. stream is sourced from a camera versus a screen capture? This would
allow the receiving party to tune, e.g., output filters. It would
appear that H.263 has this kind of indicator built into its
bitstream, but I found no analog in H.264 or VP8.
4. Stream Orientation
In some circumstances - and notably those involving mobile devices -
the orientation of the camera may not match the orientation used by
the encoder. Of more importance, the orientation may change over the
course of a call, requiring the receiver to change the orientation in
which it renders the stream.
While the sender may elect to simply change the pre-encoding
orientation of frames, this may not be practical or efficient (in
particular, in cases where the interface to the camera returns pre-
compressed video frames). Note that the potential for this behavior
adds another set of circumstances under which the resolution of a
screen might change in the middle of a video stream, in addition to
those mentioned under "Screen Sourced Video," above.
To accommodate these circumstances, RTCWEB implementations SHOULD
support generating and receiving the R0 and R1 bits of the
Coordination of Video Orientation (CVO) mechanism described in
section 7.4.5 of [TS26.114]. (TODO: Is "SHOULD support" the right
level here?) They MAY support the other bits in the CVO extension,
including the higher-resolution rotation bits.
Further, some codecs support in-band signaling of orientation (for
example, the SEI "Display Orientation" messages in H.264 and H.265).
If CVO has been negotiated, then the sender MUST NOT make use of such
codec-specific mechanisms. However, when support for CVO is not
signaled in the SDP, then such implementations MAY make use of the
codec-specific mechanisms instead.
5. Codec-Specific Considerations
WebRTC endpoints are not required to support the codecs mentioned in
this section.
However, to foster interoperability between endpoints that have However, to foster interoperability between endpoints that have
codecs in common, if they do support one of the listed codecs, then codecs in common, if they do support one of the listed codecs, then
they need to meet the requirements specified in the subsection for they need to meet the requirements specified in the subsection for
that codec. that codec.
All codecs MUST support at least 10 frames per second (fps) and SDP allows for codec-independent indication of preferred video
SHOULD support 30 fps. All codecs MUST support a minimum resolution resolutions using the mechanism described in [RFC6236]. If a
of 320X240. recipient of video indicates a receiving resolution, the sender
SHOULD accommodate this resolution, as the receiver may not be
capable of handling higher resolutions.
TODO: These are strawman values. Are they adequate? Additionally, codecs may include codec-specific means of signaling
maximum receiver abilities with regards to resolution, frame rate,
and bitrate.
4.1. VP8 Unless otherwise signaled in SDP, recipients of video streams are
MUST be able to decode video at a rate of at least 20 fps at a
resolution of at least 320x240. These values are selected based on
the recommendations in [HSUP1].
Encoders are encouraged to support encoding media with at least the
same resolution and frame rates cited above.
5.1. VP8
If VP8, defined in [RFC6386], is supported, then the endpoint MUST If VP8, defined in [RFC6386], is supported, then the endpoint MUST
support the payload formats defined in [I-D.ietf-payload-vp8]. In support the payload formats defined in [I-D.ietf-payload-vp8]. In
addition it MUST support the 'bilinear' and 'none' reconstruction addition it MUST support the 'bilinear' and 'none' reconstruction
filters. filters.
4.2. H.264 In addition to the [RFC6236] mechanism, H.264 encoders MUST limit the
streams they send to conform to the values indicated by receivers in
the corresponding max-fr and max-fs SDP attributes.
TODO: There have been claims that VP8 already requires supporting
both filters; if true, these do not need to be reiterated here.
5.2. H.264
If [H264] is supported, then the device MUST support the payload If [H264] is supported, then the device MUST support the payload
formats defined in [RFC6184]. In addition, they MUST support formats defined in [RFC6184]. In addition, they MUST support
Constrained Baseline Profile Level 1.2, and they SHOULD support H.264 Constrained Baseline Profile Level 1.2, and they SHOULD support H.264
Constrained High Profile Level 1.3. Constrained High Profile Level 1.3.
TODO: What packetization modes MUST be supported? Implementations of the H.264 codec have utilized a wide variety of
optional parameters. To improve interoperability the following
4.3. VP9 parameter settings are specified:
If VP9, as defined in [I-D.grange-vp9-bitstream], is supported, then
the device MUST support the payload formats defined in TODO.
TODO: The grange-vp9-bitstream draft does not really specify VP9 at
all, is there a better reference?
4.4. H.265 packetization-mode: Packetization-mode 1 MUST be supported. Other
modes MAY be negotiated and used.
If [H265] is supported, then the device MUST support the payload profile-level-id: Implementations MUST include this parameter within
formats defined in [I-D.ietf-payload-rtp-h265]. SDP and SHOULD interpret it when receiving it.
5. Dealing with Packet Loss max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: These par
ameters allow the implementation to specify that they can support
certain features of H.264 at higher rates and values than those
signalled by their level (set with profile-level-id).
Implementations MAY include these parameters in their SDP, but
SHOULD interpret them when receiving them, allowing them to send
the highest quality of video possible.
This section provides recommendations on how to encode video to be sprop-parameter-sets: H.264 allows sequence and picture information
robust to packet loss. to be sent both in-band, and out-of-band. WebRTC implementations
MUST signal this information in-band; as a result, this parameter
will not be present in SDP.
TODO: What do we want to require in terms of FEC, RTX, interleaving, TODO: Do we need to require the handling of specific SEI messages?
etc? One example that has been raised is freeze-frame messages.
6. Mandatory to Implement Video Codec 6. Mandatory to Implement Video Codec
Note: This section is here purely as a placeholder and there is not Note: This section is here purely as a placeholder, as there is not
yet WG Consensus on Mandatory to Implement video codecs. The WG has yet WG Consensus on Mandatory to Implement video codecs. The issue
agreed not to discuss this topic until September 29, 2014 so that the is more complicated than may be immediately apparent to newcomers,
WG can focus on getting other work done. Please, save your comments who are strongly encouraged to familiarize themselves with the
on this topic until that time. previous discussions on the topic before engaging on this issue.
The currently recorded working group consensus is that all The currently recorded working group consensus is that all
implementations MUST support a single, specified mandatory-to- implementations MUST support a single, specified mandatory-to-
implement codec. The remaining decision point is a selection of this implement codec. The remaining decision point is a selection of this
single codec. single codec.
6.1. Temperature of Working Group 6.1. Temperature of Working Group
To capture the conversation so far, this section summarizes the To capture the conversation so far, this section summarizes the
result of a straw poll that the working group undertook in December result of a straw poll that the working group undertook in December
2013 and January 2014. Respondants were asked to answer "Yes," 2013 and January 2014. Respondents were asked to answer "Yes,"
"Acceptable," or "No" for each option. The options were collected "Acceptable," or "No" for each option. The options were collected
from the working group at large prior to the initiation of the straw from the working group at large prior to the initiation of the straw
poll. poll.
Yes Acc No Yes Acc No
--- --- --- --- --- ---
1. All entities MUST support H.264 48% 11% 41% 1. All entities MUST support H.264 48% 11% 41%
2. All entities MUST support VP8 41% 17% 42% 2. All entities MUST support VP8 41% 17% 42%
3. All entities MUST support both H.264 and VP8 9% 38% 53% 3. All entities MUST support both H.264 and VP8 9% 38% 53%
4. Browsers MUST support both H.264 and VP8, other 4. Browsers MUST support both H.264 and VP8, other
entities MUST support at least one of H.264 entities MUST support at least one of H.264
and VP8 11% 34% 55% and VP8 11% 34% 55%
5. All entities MUST support at least one of 5. All entities MUST support at least one of
H.264 and VP8 10% 16% 74% H.264 and VP8 10% 16% 74%
6. All entities MUST support H.261 5% 23% 72% 6. All entities MUST support H.261 5% 23% 72%
7. There is no MTI video codec 12% 30% 58% 7. There is no MTI video codec 12% 30% 58%
8. All entities MUST support H.261 and allentities 8. All entities MUST support H.261 and all entities
MUST support at least one of H.264 and VP8 4% 28% 68% MUST support at least one of H.264 and VP8 4% 28% 68%
9. All entities MUST support Theora 7% 26% 67% 9. All entities MUST support Theora 7% 26% 67%
10. All entities MUST implement at least two of 10. All entities MUST implement at least two of
{VP8, H.264, H.261} 5% 30% 65% {VP8, H.264, H.261} 5% 30% 65%
11. All entities MUST implement at least two of 11. All entities MUST implement at least two of
{VP8, H.264, H.263} 5% 25% 70% {VP8, H.264, H.263} 5% 25% 70%
12. All entities MUST support decoding using both 12. All entities MUST support decoding using both
H.264 and VP8, and MUST support encoding using H.264 and VP8, and MUST support encoding using
at least one of H.264 or VP8 7% 20% 73% at least one of H.264 or VP8 7% 20% 73%
13. All entities MUST support H.263 6% 19% 75% 13. All entities MUST support H.263 6% 19% 75%
14. All entities MUST implement at least two of 14. All entities MUST implement at least two of
{VP8, H.264, Theora} 6% 27% 67% {VP8, H.264, Theora} 6% 27% 67%
skipping to change at page 6, line 4 skipping to change at page 7, line 29
This specification does not introduce any new mechanisms or security This specification does not introduce any new mechanisms or security
concerns beyond what the other documents it references. In WebRTC, concerns beyond what the other documents it references. In WebRTC,
video is protected using DTLS/SRTP. A complete discussion of the video is protected using DTLS/SRTP. A complete discussion of the
security can be found in [I-D.ietf-rtcweb-security] and security can be found in [I-D.ietf-rtcweb-security] and
[I-D.ietf-rtcweb-security-arch]. Implementers should consider [I-D.ietf-rtcweb-security-arch]. Implementers should consider
whether the use of variable bit rate video codecs are appropriate for whether the use of variable bit rate video codecs are appropriate for
their application based on [RFC6562]. their application based on [RFC6562].
8. IANA Considerations 8. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank <GET YOUR NAME HERE - PLEASE SEND The authors would like to thank Gaelle Martin-Cocher, Stephan Wenger,
COMMENTS>. Thanks to Cullen Jennings for providing text and review. and Bernard Aboba for their detailed feedback and assistance with
This draft includes text from draft-cbran-rtcweb-codec. this document. Thanks to Cullen Jennings for providing text and
review. This draft includes text from draft-cbran-rtcweb-codec.
10. References 10. References
10.1. Normative References 10.1. Normative References
[H264] ITU-T Recommendation H.264, "Advanced video coding for [H264] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services", April 2013. generic audiovisual services", April 2013.
[H265] ITU-T Recommendation H.265, "High efficiency video [HSUP1] ITU-T Recommendation H.Sup1, "Application profile - Sign
coding", April 2013. language and lip-reading real-time conversation using low
bit rate video communication", May 1999.
[I-D.grange-vp9-bitstream]
Grange, A. and H. Alvestrand, "A VP9 Bitstream Overview",
draft-grange-vp9-bitstream-00 (work in progress), February
2013.
[I-D.ietf-payload-rtp-h265]
Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M.
Hannuksela, "RTP Payload Format for High Efficiency Video
Coding", draft-ietf-payload-rtp-h265-04 (work in
progress), May 2014.
[I-D.ietf-payload-vp8] [I-D.ietf-payload-vp8]
Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", draft-ietf- Galligan, "RTP Payload Format for VP8 Video", draft-ietf-
payload-vp8-11 (work in progress), February 2014. payload-vp8-11 (work in progress), February 2014.
[IEC23001-8]
ISO/IEC 23001-8:2013/DCOR1, "Coding independent media
description code points", 2013.
[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.
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
Uncompressed Video", RFC 4175, September 2005. Uncompressed Video", RFC 4175, September 2005.
[RFC4421] Perkins, C., "RTP Payload Format for Uncompressed Video: [RFC4421] Perkins, C., "RTP Payload Format for Uncompressed Video:
Additional Colour Sampling Modes", RFC 4421, February Additional Colour Sampling Modes", RFC 4421, February
2006. 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008.
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184, May 2011. Payload Format for H.264 Video", RFC 6184, May 2011.
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in the Session Description Protocol (SDP)", RFC
6236, May 2011.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
Guide", RFC 6386, November 2011. Guide", RFC 6386, November 2011.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP", RFC 6562, March Variable Bit Rate Audio with Secure RTP", RFC 6562, March
2012. 2012.
[SRGB] IEC 61966-2-1, "Multimedia systems and equipment - Colour
measurement and management - Part 2-1: Colour management -
Default RGB colour space - sRGB.", October 1999.
[TS26.114]
3GPP TS 26.114 V12.7.0, "3rd Generation Partnership
Project; Technical Specification Group Services and System
Aspects; IP Multimedia Subsystem (IMS); Multimedia
Telephony; Media handling and interaction (Release 12)",
September 2014.
10.2. Informative References 10.2. Informative References
[I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-06 (work in progress),
February 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-09 (work in progress), February 2014. rtcweb-security-arch-09 (work in progress), February 2014.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-06 (work in progress), January 2014. ietf-rtcweb-security-06 (work in progress), January 2014.
Author's Address Author's Address
 End of changes. 37 change blocks. 
80 lines changed or deleted 178 lines changed or added

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