idnits 2.17.1 draft-guduru-rtcweb-codec-preferences-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: createOffer and createAnswer methods supports optional "RTCOfferAnswerOptions" attribute. This specification extends RTCOfferAnswerOptions with optional preferredAudioCodecs and preferredVideoCodecs attributes, to set the audio and video codec preferences respectively. preferredAudioCodecs and preferredVideoCodecs, if present in RTCOfferAnswerOptions, contains a sequence of audio and video codecs in applications preferred order. If the application does not want to specify any codec preference, then these attributes MUST not be added to RTCOfferAnswerOptions. -- The document date (January 5, 2015) is 3399 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-rtcweb-audio-05 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-06 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 ** Downref: Normative reference to an Informational draft: draft-ietf-rtcweb-use-cases-and-requirements (ref. 'I-D.ietf-rtcweb-use-cases-and-requirements') Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtcweb K. Guduru 3 Internet-Draft Samsung Electronics 4 Intended status: Standards Track January 5, 2015 5 Expires: July 9, 2015 7 WebRTC Codec Preferences 8 draft-guduru-rtcweb-codec-preferences-02 10 Abstract 12 WebRTC specifies to implement a minimum set of required codecs to 13 ensure guaranteed interoperability between WebRTC peers. WebRTC 14 allows browser implementers to support vendor specific codecs apart 15 from mandatory codecs. This document specifies the way for 16 JavaScript applications to give preferences for media codecs in 17 WebRTC context out of the available codecs in browser for creating 18 the offer / answer. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 9, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Retrieving Supported Codecs . . . . . . . . . . . . . . . . . 3 57 3.1. getSupportedAudioCodecs . . . . . . . . . . . . . . . . . . 3 58 3.2. getSupportedVideoCodecs . . . . . . . . . . . . . . . . . . 3 59 4. Retrieving Codec Preferences . . . . . . . . . . . . . . . . 3 60 4.1. getCodecPreferences . . . . . . . . . . . . . . . . . . . . 3 61 5. Setting Codec Preferences . . . . . . . . . . . . . . . . . . 4 62 5.1. setCodecPreferences . . . . . . . . . . . . . . . . . . . . 4 63 5.2. RTCOfferAnswerOptions . . . . . . . . . . . . . . . . . . . 4 64 5.2.1. preferredAudioCodecs . . . . . . . . . . . . . . . . . . 4 65 5.2.2. preferredVideoCodecs . . . . . . . . . . . . . . . . . . 4 66 6. Generating SDP . . . . . . . . . . . . . . . . . . . . . . . 4 67 7. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 WebRTC specifies to implement mandatory codecs inside the browser to 78 ensure guaranteed interoperability between browsers and to increase 79 the session establishment success rate [I-D.ietf-rtcweb-audio]. 80 WebRTC specifications allows browser implementors to support codecs 81 apart from mandatory codecs. This specification describes a 82 mechanism for JavaScript application to check the available codecs, 83 to set preferences among the available codecs and provision to remove 84 codecs from the SDP, if the application don't want to use them. This 85 specification extends RTCPeerConnection [I-D.ietf-rtcweb-jsep] by 86 adding two new methods, getSupportedAudioCodecs and 87 getSupportedVideoCodecs for retrieving codecs supported by browser, 88 RTCRTPSender and RTCRTPReceiver for setting the codec preferences and 89 for retrieving the previously configured codec preferences of 90 accepted tracks. It also extends offer / answer options with 91 sequences of audio and video codec list to set codec preferences for 92 accepted tracks without codec preferences set and for future tracks. 93 These preferences are used for preparing the SDP when subsequent 94 createOffer or createAnswer is called. This specification fulfils 95 the requirement to provide API for web application to control media 96 format, API requirement A5 specified in 98 [I-D.ietf-rtcweb-use-cases-and-requirements], and avoids the SDP 99 mangling for removing and re-ordering of codecs. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 3. Retrieving Supported Codecs 109 This specification allows JS application to retrieve audio and video 110 codecs supported by the browser. 112 3.1. getSupportedAudioCodecs 114 The getSupportedAudioCodes method of RTCPeerConnection returns a 115 sequence of audio codecs supported by browser. This sequence SHOULD 116 solely contain all the audio codecs that are supported by browser. 117 This function can be called from the JavaScript application at any 118 time after creating the peerConnection and before closing the 119 peerConnection. 121 3.2. getSupportedVideoCodecs 123 The getSupportedVideoCodes method of RTCPeerConnection returns a 124 sequence of video codecs supported by browser. This sequence SHOULD 125 solely contain all the video codecs that are supported by browser. 126 This function can be called from the JavaScript application at any 127 time after creating the peerConnection and before closing the 128 peerConnection. 130 4. Retrieving Codec Preferences 132 This specification provides an API for Java Script application to 133 retrieve the list of codec preferences that were previously set. 135 4.1. getCodecPreferences 137 The getCodecPreferences method of RTCRTPSender / RTCRTPReceiver 138 returns a sequence of codecs, if set earlier. The order of codecs in 139 this sequence SHOULD be same as that previously set by the 140 application. The sequence contains a list of audio codecs, if the 141 MediaStreamTrack of RTCRTPSender / RTCRTPReceiver is of type audio. 142 The sequence contains a list of video codecs, if the MediaStreamTrack 143 of RTCRTPSender / RTCRTPReceiver is of type video. 145 5. Setting Codec Preferences 147 This specification provides API for Java Script application to set 148 the sequence of codec preferences. The order of codecs in this 149 sequence SHOULD be in the order preferred by the JavaScript 150 application. Codec preferences can be set through RTCRTPSender / 151 RTCRTPReceiver or through RTCOfferAnswerOptions. 153 5.1. setCodecPreferences 155 The setCodecPreferences method of RTCRTPSender / RTCRTPReceiver sets 156 the codec preferences for accepted tracks. The sequence of codecs 157 SHOULD be in the order specified by Java script application. The 158 sequence of codecs MUST be of kind audio, if the MediaStreamTrack of 159 RTCRTPSender / RTCRTPReceiver is of type audio. The sequence of 160 codecs MUST be of kind video, if the MediaStreamTrack of RTCRTPSender 161 / RTCRTPReceiver is of type video. 163 5.2. RTCOfferAnswerOptions 165 createOffer and createAnswer methods supports optional 166 "RTCOfferAnswerOptions" attribute. This specification extends 167 RTCOfferAnswerOptions with optional preferredAudioCodecs and 168 preferredVideoCodecs attributes, to set the audio and video codec 169 preferences respectively. preferredAudioCodecs and 170 preferredVideoCodecs, if present in RTCOfferAnswerOptions, contains a 171 sequence of audio and video codecs in applications preferred order. 172 If the application does not want to specify any codec preference, 173 then these attributes MUST not be added to RTCOfferAnswerOptions. 175 5.2.1. preferredAudioCodecs 177 preferredAudioCodecs, is an optional constraint which SHOULD contain 178 a sequence of audio codecs in applications preferred order. 180 5.2.2. preferredVideoCodecs 182 preferredVideoCodecs, is an optional constraint which SHOULD contain 183 a sequence of video codecs in applications preferred order. 185 6. Generating SDP 187 JavaScript application can set the codec preferences in browser 188 through setCodecPreferences method or RTCOfferAnswerOptions. The 189 setCodecPreferences will not immediately change the existing codec in 190 encoder or decoder of accepted tracks. It preserves the codec 191 preferences until createOffer / createAnswer method is invoked for 192 the next time, and considers updated codec preferences for generating 193 the new SDP. 195 The preferred codec sequence MAY contain the same number of audio 196 codecs or video codecs returned by getSupportedAudioCodecs / 197 getSupportedVideoCodecs respectively. Sequence of codecs, preferred 198 by the application, MUST contain at least one codec returned by 199 getSupportedAudioCodecs / getSupportedVideoCodecs. Codecs other than 200 those supported by browser SHOULD be ignored, if present in sequence 201 of codecs that were set by the application. The offer / answer 202 SHOULD NOT contain audio codecs other than those specified by 203 JavaScript application and the order of preference SHOULD be with 204 high priority for the codecs first in the sequence. 206 For generating the SDP, codecs SHOULD be prioritized as per the 207 preferences set through setCodecPreferences. If preferences were not 208 set through setCodecPreferences, codecs SHOULD be prioritized as per 209 the preferences set through RTCOfferAnswerOptions. If the 210 preferences were not set either through setCodecPreferences or 211 RTCOfferAnswerOptions, then SDP will be generated with implementation 212 specific codecs preferences. 214 7. Usecases 216 Many codecs are available for encoding and decoding audio, video data 217 with their own advantages and disadvantages. Applications MAY use 218 any of the available codecs in browser based on its requirements like 219 providing high quality, reduced bandwidth usage, reduced power usage. 220 The requirements for prioritizing a codec MAY change after 221 establishing the session. 223 Bandwidth availability may not be same for a complete session. User 224 may increase or decrease the bandwidth provided, by communicating 225 with network provider, while the session is ongoing. The bandwidth 226 availability may change because of network congestions. Some codecs 227 performs pretty good at higher bandwidths while some other codecs 228 perform well at lower bandwidths. The performance of single codec at 229 all the bandwidth ranges is not same, which demands to use different 230 codecs at different bandwidth availability. 232 Battery usage is a big concern in mobile devices. Some codecs may 233 use less power with the tradeoff of bandwidth / quality. At times of 234 less available battery charging, users may like to continue the 235 conversation for more time with slightly reduced quality, leading to 236 a requirement to change the priority of codecs during an active 237 session. 239 8. Example 241 Consider an example where a browser implementation supports G.722 and 242 AMR-WB apart from OPUS and G.711 as audio codecs. Let the browser 243 default order of priority for audio codecs be G.722, AMR-WB, OPUS and 244 G.711. Then the partial SDP representing audio codecs, that is 245 generated as a result of createOffer or createAnswer will be as 246 follows. 248 m=audio 1 RTP/SAVPF 103 109 111 0 8 126 249 a=mid:audio 250 a=rtpmap:103 g722/8000 251 a=rtpmap:109 AMR/8000/1 252 a=rtpmap:111 opus/48000/2 253 a=rtpmap:0 PCMU/8000 254 a=rtpmap:8 PCMA/8000 255 a=rtpmap:126 telephone-event/8000 257 If the application wants to modify the audio codec preference to AMR- 258 WB, OPUS, G.722 and G.711, then JavaScript application will retrieve 259 the supported codecs and set the codec preferences accordingly. Then 260 the partial SDP representing audio codecs, generated through 261 createOffer / createAnswer will generate the SDP with the codecs in 262 application's preferred order. 264 m=audio 1 RTP/SAVPF 109 111 103 0 8 126 265 a=mid:audio 266 a=rtpmap:109 AMR/8000/1 267 a=rtpmap:111 opus/48000/2 268 a=rtpmap:103 g722/8000 269 a=rtpmap:0 PCMU/8000 270 a=rtpmap:8 PCMA/8000 271 a=rtpmap:126 telephone-event/8000 273 9. Security Considerations 275 TBD. 277 10. IANA Considerations 279 This document requires no actions from IANA. 281 11. Acknowledgements 283 I would like to thank Justin Uberti and Harald Alvestrand for their 284 valuable comments and suggestions. 286 12. Normative References 288 [I-D.ietf-rtcweb-audio] 289 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 290 Requirements", draft-ietf-rtcweb-audio-05 (work in 291 progress), February 2014. 293 [I-D.ietf-rtcweb-jsep] 294 Uberti, J. and C. Jennings, "Javascript Session 295 Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work 296 in progress), February 2014. 298 [I-D.ietf-rtcweb-use-cases-and-requirements] 299 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 300 Time Communication Use-cases and Requirements", draft- 301 ietf-rtcweb-use-cases-and-requirements-14 (work in 302 progress), February 2014. 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 Author's Address 309 Kiran Kumar Guduru 310 Samsung Electronics 311 Samsung RnD Institute India - Bangalore 312 Bangalore, Doddanakundi 560037 313 India 315 Phone: +91-888-4995166 316 Email: kiran.guduru@samsung.com