moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.4

Browse Source
This commit is contained in:
stpeter 2011-06-09 09:51:55 -06:00
parent eea8f5b955
commit b9f965ff84
1 changed files with 129 additions and 118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

247
xep-0266.xml
View File

@ -11,7 +11,7 @@
&LEGALNOTICE;
<number>0266</number>
<status>Experimental</status>
<type>Informational</type>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
@ -23,6 +23,12 @@
<shortname>N/A</shortname>
<discuss>jingle</discuss>
&stpeter;
<revision>
<version>0.4</version>
<date>2011-06-09</date>
<initials>psa</initials>
<remark><p>Recommended G.711 as mandatory-to-implement for audio.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2011-01-12</date>
@ -79,133 +85,138 @@
<di><dt>Quality</dt><dd>The encoding quality is acceptable for deployment among XMPP users.</dd></di>
<di><dt>Packetization</dt><dd>The specification of the codec clearly defines packetization of data for sending over RTP.</dd></di>
<di><dt>Availability</dt><dd>The codec can be implemented on a wide variety of computing platforms and is commonly used in Internet or other systems.</dd></di>
<di><dt>Patents</dt><dd>The codec is patent-clear. <note>The term patent-clear does not necessarily mean that no patents have ever been applied for or granted regarding a technology, or that the technology is completely free from patents (since such a judgment is nearly impossible to make, and is outside the purview of the XMPP developer community and the XMPP Standards Foundation); the term means only that those who implement the technology are generally understood to be relatively safe from the threat of patent litigation, either because any relevant patents have expired, were filed in a defensive manner, or are made available under suitable royalty-free licenses.</note></dd></di>
<di><dt>Patents</dt><dd>The codec is patent-clear. <note>The term patent-clear does not necessarily mean that no patents have ever been applied for or granted regarding a technology, or that the technology is completely free from patents (since such a judgment is nearly impossible to make, and is outside the purview of the XMPP developer community and the XMPP Standards Foundation); the term means only that those who implement the technology are generally understood to be relatively safe from the threat of patent litigation, either because any relevant patents have expired, were filed in a defensive manner, or are made available under suitable royalty-free licenses.</note> (Although most XMPP developers would prefer to implement codecs that are patent-clear, such options are not always widely implemented and deployed.)</dd></di>
</dl>
<p>Unfortunately, not all codecs are ideal. In the next section we discuss the audio and video codecs that are most attractive for implementation in Jingle RTP applications.</p>
<p>Note: In general, audio codecs are more mature than video codecs. As a result, there are more patent-clear options for audio than for video. Although most XMPP developers would prefer to implement codecs that are patent-clear (both for ethical reasons and to produce free or at least affordable software), such options are not always widely implemented and deployed. This document takes these factors into account.</p>
<p>Unfortunately, not all codecs are ideal. In the remainder of this document we discuss the audio and video codecs that are most appropriate for implementation in Jingle RTP applications.</p>
</section1>
<section1 topic='Codec Summary' anchor='summary'>
<section2 topic='Audio' anchor='audio'>
<section3 topic='G.711' anchor='audio-g711'>
<p>G.711 refers to the Pulse Code Modulation (PCM) codec defined in &ITU; recommendation G.711, which is widely used on the public switched telephone network (PSTN) and by many voice over Internet Protocol (VoIP) providers. There are two versions: the &#956;-law ("U-law") version is widely deployed in North America and in Japan and the A-law version is widely deployed in the rest of the world. The following table summarizes the available information about G.711.</p>
<table caption='Codec Considerations for G.711'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>Good quality; no wide-band mode.</td>
<td>See &rfc5391;.</td>
<td>Commonly deployed in both PSTN and VoIP systems.</td>
<td>Developed in 1972; patents have expired.</td>
</tr>
</table>
</section3>
<section3 topic='Opus' anchor='audio-opus'>
<p>The Opus codec is under development within the IETF's <link url='http://tools.ietf.org/wg/codec/'>Codec Working Group</link>. In essence it combines the best features of CELT (developed by Jean-Marc Valin, the creator of Speex) and SILK (created by and widely used in the Skype). The following table summarizes the available information about Opus.</p>
<table caption='Codec Considerations for Opus'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>Extremely high quality; can be used for wide-band audio.</td>
<td>Not yet defined.</td>
<td>Covered under IETF IPR rules, the intent it for the codec to be covered under a simplified BSD license. See <link url='http://tools.ietf.org/html/draft-ietf-codec-opus'>http://tools.ietf.org/html/draft-ietf-codec-opus</link> for details. Not commonly deployed yet, but the SILK codec on which it is partly based is very widely deployed.</td>
<td>Designed to be patent-clear, but IPR claims have been filed.</td>
</tr>
</table>
</section3>
<section3 topic='Speex' anchor='audio-speex'>
<p>According to the speex.org website, the Speex codec is "an Open Source/Free Software patent-free audio compression format designed for speech". Speex was developed by Jean-Marc Valin and is maintained by the <link url='http://www.xiph.org/'>Xiph.org Foundation</link>. The following table summarizes the available information about Speex.</p>
<table caption='Codec Considerations for Speex'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>Good quality; optimized for voice; can be used for wide-band audio.</td>
<td>See &rfc5574;.</td>
<td>Freely downloadable under a revised BSD license at &lt;<link url='http://speex.org/'>http://speex.org/</link>&gt; and commonly deployed on Internet (VoIP) systems; not commonly deployed on non-Internet systems.</td>
<td>Designed to be patent-clear.</td>
</tr>
</table>
</section3>
<section1 topic='Audio Codecs' anchor='audio'>
<section2 topic='G.711' anchor='audio-g711'>
<p>G.711 refers to the Pulse Code Modulation (PCM) codec defined in &ITU; recommendation G.711, which is widely used on the public switched telephone network (PSTN) and by many voice over Internet Protocol (VoIP) providers. There are two versions: the &#956;-law ("U-law") version is widely deployed in North America and in Japan, whereas the A-law version is widely deployed in the rest of the world. The following table summarizes the available information about G.711.</p>
<table caption='Codec Considerations for G.711'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>Good quality; no wide-band mode.</td>
<td>See &rfc5391;.</td>
<td>Commonly deployed in both PSTN and VoIP systems.</td>
<td>Developed in 1972; patents have expired.</td>
</tr>
</table>
</section2>
<section2 topic='Video' anchor='video'>
<section3 topic='Dirac' anchor='video-dirac'>
<p>Dirac is a general-purpose video compression technology developed by the BBC that has been licensed in the open. It is used for everything from Internet streaming to HDTV. To date there is no RTP packetization deveintion for Dirac; however, such a format is under development.</p>
<table caption='Codec Considerations for Dirac'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<section2 topic='Opus' anchor='audio-opus'>
<p>The Opus codec is under development within the IETF's <link url='http://tools.ietf.org/wg/codec/'>Codec Working Group</link>. In essence it combines the best features of CELT (developed by Jean-Marc Valin, the creator of Speex) and SILK (created by and widely used in the Skype service). The following table summarizes the available information about Opus.</p>
<table caption='Codec Considerations for Opus'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>Extremely high quality; can be used for wide-band audio.</td>
<td>Not yet defined.</td>
<td>Covered under IETF IPR rules, the intent is for the codec to be covered under a simplified BSD license. See <link url='http://tools.ietf.org/html/draft-ietf-codec-opus'>http://tools.ietf.org/html/draft-ietf-codec-opus</link> for details. Not commonly deployed yet, but the SILK codec on which it is partly based is very widely deployed.</td>
<td>Designed to be patent-clear, but IPR claims have been filed.</td>
</tr>
</table>
</section2>
<section2 topic='Speex' anchor='audio-speex'>
<p>According to the speex.org website, the Speex codec is "an Open Source/Free Software patent-free audio compression format designed for speech". Speex was developed by Jean-Marc Valin and is maintained by the <link url='http://www.xiph.org/'>Xiph.org Foundation</link>. The following table summarizes the available information about Speex.</p>
<table caption='Codec Considerations for Speex'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>High quality.</td>
<td>Not yet defined.</td>
<td>Freely downloadable under both GPL and LGPL at &lt;<link url='http://diracvideo.org/'>http://diracvideo.org/</link>&gt;; commonly deployed but not yet in video over IP systems because of the lack of an RTP packetization format.</td>
<td>Diract is patent-clear, and the BBC has allowed its related patents to lapse.</td>
</tr>
</table>
</section3>
<section3 topic='H.264' anchor='video-h264'>
<p>H.264 is a technology for video compression jointly designed by the ITU and the &ISO;. The following table summarizes the available information about H.264.</p>
<table caption='Codec Considerations for H.264'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>High quality.</td>
<td>See &rfc3984;.</td>
<td>Commonly deployed in commercial video systems. Not freely downloadable; both software implementations and service deployments can be subject to royalty payments for commercial use.</td>
<td>Patented.</td>
</tr>
</table>
</section3>
<section3 topic='Theora' anchor='video-theora'>
<p>According to the theora.org website, the Theora codec is "a free and open video compression format". Theora is based on the VP3 codec originally developed by On2 Technologies and is now maintained by the <link url='http://www.xiph.org/'>Xiph.org Foundation</link>. The following table summarizes the available information about Theora.</p>
<table caption='Codec Considerations for Theora'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>Acceptable quality.</td>
<td>See &rtptheora;.</td>
<td>Freely downloadable under BSD license at &lt;<link url='http://theora.org/'>http://theora.org/</link>&gt;; not yet commonly deployed, especially on devices that have deployed H.264 instead.</td>
<td>On2's patents over VP3 were contributed to the Xiph.org Foundation in 2001.</td>
</tr>
</table>
</section3>
<th>Patents</th>
</tr>
<tr>
<td>Good quality; optimized for voice; can be used for wide-band audio.</td>
<td>See &rfc5574;.</td>
<td>Freely downloadable under a revised BSD license at &lt;<link url='http://speex.org/'>http://speex.org/</link>&gt; and commonly deployed on Internet (VoIP) systems; not commonly deployed on non-Internet systems.</td>
<td>Designed to be patent-clear.</td>
</tr>
</table>
</section2>
<section2 topic='Guidance for Implementers' anchor='audio-impl'>
<p>Given that both Speex and G.711 are patent-clear, freely implementable, and commonly deployed, implementers are encouraged to consider including support for both codecs in audio applications of Jingle RTP sessions. Discussion on the jingle@xmpp.org mailing list indicates a slight preference for G.711 because it is so widely deployed and easily available. The Opus codec is not yet widely deployed (or even fully developed), but it might become the "codec of the future" for audio applications over the Internet.</p>
</section2>
<section2 topic='Mandatory-to-Implement Codec' anchor='audio-mti'>
<p>As of June 2011, this document makes the following recommendations:</p>
<ol>
<li>Jingle clients MUST implement both PCMU and PCMA.</li>
<li>Gateways between Jingle networks and other networks (e.g., SIP networks and the PSTN) MUST implement either PCMA or PCMA.</li>
</ol>
<p>Naturally, clients and gateways can implement additional codecs, such as those listed in this document.</p>
</section2>
</section1>
<section1 topic='Guidance for Implementors' anchor='guidance'>
<p>Given that both Speex and G.711 are patent-clear, freely implementable, and commonly deployed, this document suggests that implementors strongly consider including support for both codecs in audio applications of Jingle RTP sessions. Discussion on the jingle@xmpp.org mailing list indicates a slight preference for G.711 because it is so widely deployed and easily available. The Opus codec is not yet widely deployed (or even fully developed), but it might become the "codec of the future" for audio applications over the Internet.</p>
<p>The situation regarding video codecs is more murky, and implementors face difficult tradeoffs. While Theora is patent-clear and freely implementable, it is not yet commonly deployed. While Dirac is patent-clear and deployed fairly widely, no RTP packetization format has been defined for it. While deployment of H.264 is fairly common, it is not patent-clear or freely implementable. For many open-source / free software projects and smaller technology vendors, implementation of H.264 is either impossible (because of patents and licensing restrictions) or prohibitively expensive (because of royalty payments). These developers are strongly encouraged to implement Theora or Dirac and also to urge wider adoption of Theora and Dirac among larger technology vendors. However, this document acknowledges that it may take some time before Theora and Dirac are commonly deployed (especially on mobile devices) and that systems based on H.264 might be dominant in the marketplace for several years. This situation is unfortunate but cannot be directly changed by the XMPP developer community.</p>
</section1>
<section1 topic='Recommendations to the XSF' anchor='recommendations'>
<p>This document suggests that both Speex and G.711 could be recommended as mandatory-to-implement technologies for audio codecs, should the XSF decide to make such recommendations.</p>
<p>This document suggests that at this time it is not possible for the XSF to recommend a mandatory-to-implement technology for video codecs, but that it might be possible for the XSF to recommend Theora or Dirac in the future if they are more widely adopted.</p>
<section1 topic='Video' anchor='video'>
<section2 topic='Dirac' anchor='video-dirac'>
<p>Dirac is a general-purpose video compression technology developed by the BBC that has been licensed in the open. It is used for everything from Internet streaming to HDTV. To date there is no RTP packetization deveintion for Dirac; however, such a format is under development.</p>
<table caption='Codec Considerations for Dirac'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>High quality.</td>
<td>Not yet defined.</td>
<td>Freely downloadable under both GPL and LGPL at &lt;<link url='http://diracvideo.org/'>http://diracvideo.org/</link>&gt;; commonly deployed but not yet in video over IP systems because of the lack of an RTP packetization format.</td>
<td>Diract is patent-clear, and the BBC has allowed its related patents to lapse.</td>
</tr>
</table>
</section2>
<section2 topic='H.264' anchor='video-h264'>
<p>H.264 is a technology for video compression jointly designed by the ITU and the &ISO;. The following table summarizes the available information about H.264.</p>
<table caption='Codec Considerations for H.264'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>High quality.</td>
<td>See &rfc3984;.</td>
<td>Commonly deployed in commercial video systems. Not freely downloadable; both software implementations and service deployments can be subject to royalty payments for commercial use.</td>
<td>Patented.</td>
</tr>
</table>
</section2>
<section2 topic='Theora' anchor='video-theora'>
<p>According to the theora.org website, the Theora codec is "a free and open video compression format". Theora is based on the VP3 codec originally developed by On2 Technologies and is now maintained by the <link url='http://www.xiph.org/'>Xiph.org Foundation</link>. The following table summarizes the available information about Theora.</p>
<table caption='Codec Considerations for Theora'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>Acceptable quality.</td>
<td>See &rtptheora;.</td>
<td>Freely downloadable under BSD license at &lt;<link url='http://theora.org/'>http://theora.org/</link>&gt;; not yet commonly deployed, especially on devices that have deployed H.264 instead.</td>
<td>On2's patents over VP3 were contributed to the Xiph.org Foundation in 2001.</td>
</tr>
</table>
</section2>
<section2 topic='Guidance for Implementers' anchor='video-impl'>
<p>The situation regarding video codecs is more murky, and implementers face difficult tradeoffs. Although Theora is patent-clear and freely implementable, it is not yet commonly deployed. Although Dirac is patent-clear and deployed fairly widely, no RTP packetization format has been defined for it. Although deployment of H.264 is fairly common, it is not patent-clear or freely implementable. For many open-source / free software projects and smaller technology vendors, implementation of H.264 is either impossible (because of patents and licensing restrictions) or prohibitively expensive (because of royalty payments). These developers are strongly encouraged to implement Theora or Dirac and also to urge wider adoption of Theora and Dirac among larger technology vendors. However, this document acknowledges that it may take some time before Theora and Dirac are commonly deployed (especially on mobile devices) and that systems based on H.264 might be dominant in the marketplace for several years. This situation is unfortunate but cannot be directly changed by the XMPP developer community.</p>
</section2>
<section2 topic='Mandatory-to-Implement Codec' anchor='video-mti'>
<p>Because video codecs are not as mature as audio codecs, it is not yet possible for the XSF to recommend a mandatory-to-implement technology for video codecs. However, it might be possible to recommend Theora or Dirac in the future if they are more widely adopted.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>For security considerations related to Jingle RTP sessions, refer to XEP-0167. This document introduces no new security considerations. See also the security considerations sections of the relevant codec specifications.</p>
<p>For security considerations related to Jingle RTP sessions, refer to <cite>XEP-0167</cite>. This document introduces no new security considerations. See also the security considerations described in the relevant codec specifications.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
@ -217,6 +228,6 @@
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Olivier Crête, Dave Cridland, Florian Jensen, Justin Karneges, Evgeniy Khramtsov, Tobias Markmann, Pedro Melo, Jack Moffitt, Jeff Muller, Arc Riley, Kevin Smith, Justin Uberti, and Paul Witty for their feedback.</p>
<p>Thanks to Olivier Crête, Dave Cridland, Florian Jensen, Justin Karneges, Evgeniy Khramtsov, Marcus Lundblad, Tobias Markmann, Pedro Melo, Jack Moffitt, Jeff Muller, Jehan Pagès, Arc Riley, Kevin Smith, Remko Tronçon, Justin Uberti, and Paul Witty for their feedback.</p>
</section1>
</xep>