moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

0.15

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@862 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-05-25 15:43:04 +00:00
parent d834debbf1
commit ed5b16da63
1 changed files with 26 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
xep-0166.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Jingle</title>
<abstract>This document defines a framework for initiating and managing peer-to-peer multimedia sessions (e.g., voice and video exchanges) between Jabber/XMPP clients in a way that is interoperable with existing Internet standards.</abstract>
<abstract>This document defines a framework for initiating and managing peer-to-peer multimedia sessions (e.g., voice and video chat) between two Jabber/XMPP endpoints in a way that is interoperable with existing Internet standards.</abstract>
&LEGALNOTICE;
<number>0166</number>
<status>Experimental</status>
@ -26,6 +26,12 @@
&robmcqueen;
&seanegan;
&hildjj;
<revision>
<version>0.15</version>
<date>2007-05-25</date>
<initials>psa</initials>
<remark><p>Rewrote introduction and moved historical text to separate section.</p></remark>
</revision>
<revision>
<version>0.14</version>
<date>2007-04-17</date>
@ -172,33 +178,26 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>There exists no widely-adopted standard for initiating and managing peer-to-peer (p2p) interactions (such as voice, video, or file sharing exchanges) from within Jabber/XMPP clients. Although several large service providers and Jabber/XMPP clients have written and implemented their own proprietary XMPP extensions for p2p signalling (usually only for voice), those technologies are not open and do not always take into account requirements to interoperate with the Public Switched Telephone Network (PSTN) or Voice over Internet Protocol (VoIP) networks based on the IETF's Session Initiation Protocol (SIP) as specified in &rfc3261; and its various extensions.</p>
<p>By contrast, the only existing open protocol has been &xep0111;, which made it possible to initiate and manage p2p sessions, but which did not provide enough of the key signalling semantics to be easily implemented in Jabber/XMPP clients. <note>It is true that TINS made it relatively easy to implement an XMPP-to-SIP gateway; however, in line with the long-time Jabber philosophy of "simple clients, complex servers", it would be better to force complexity onto the server-side gateway and to keep the client as simple as possible.</note></p>
<p>The result has been an unfortunate fragmentation within the XMPP community regarding signalling protocols. There are, essentially, two approaches to solving the problem:</p>
<ol>
<li>Recommend that all client developers implement a dual-stack (XMPP + SIP) solution.</li>
<li>Define a full-featured protocol for XMPP signalling.</li>
</ol>
<p>Implementation experience indicates that a dual-stack approach may not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible. Therefore, it seems reasonable to define an XMPP signalling protocol that can provide the necessary signalling semantics while also making it relatively straightforward to interoperate with existing Internet standards.</p>
<p>As a result of feedback received on <cite>XEP-0111</cite>, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, <note>Google Talk is a messaging and voice chat service and client provided by Google; see &lt;<link url='http://www.google.com/talk/'>http://www.google.com/talk/</link>&gt;.</note> it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified herein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the XMPP Standards Foundation's standards process.</p>
<p>The purpose of Jingle is not to supplant or replace SIP. Because dual-stack XMPP+SIP clients are difficult to build, given that they essentially have two centers of program control, <note>For example, one large ISP recently decided to switch to a pure XMPP approach after having implemented and deployed a dual-stack client for several years.</note> we have designed Jingle as a pure XMPP signalling protocol. However, Jingle is intended to interwork with SIP so that the millions of deployed XMPP clients can be added onto the existing open VoIP networks, rather than limiting XMPP users to a separate and distinct VoIP network.</p>
<p>Furthermore, the purpose of Jingle is not to build a full-fledged telephony application, but instead to add basic voice chat, video chat, and real-time multimedia functionality (e.g., screen sharing) to existing and future XMPP clients. For this reason, the core Jingle specifications do not include support for features such as forking or call transfer. Such features may be added via optional extensions in the future, but are not needed to meet the requirements for basic multimedia interaction.</p>
<p>The purpose of Jingle is to enable one-to-one, peer-to-peer media sessions between XMPP entities, with the negotiation occurring over XMPP and the media being exchanged outside the XMPP band using technologies such as the Real-time Transport Protocol (RTP; &rfc3550;), the User Datagram Protocol (UDP; &rfc0768;), and &ice;.</p>
<p>One target application for Jingle is simple voice chat (see &xep0167;). We stress the word "simple". The purpose of Jingle is not to build a full-fledged telephony application that supports call waiting, call forwarding, call transfer, hold music, IVR systems, find-me-follow-me functionality, conference calls, and the like. These features are of interest to some user populations, but building in support for these features would introduce unnecessary complexity into a technology that is designed for basic multimedia interaction.</p>
<p>The purpose of Jingle is not to supplant or replace technologies based on Session Initiation Protocol (SIP; &rfc3261;). Because dual-stack XMPP+SIP clients are difficult to build, Jingle was designed as a pure XMPP signalling protocol. However, Jingle is at the same time designed to interwork with SIP so that the millions of deployed XMPP clients can be added onto existing Voice over Internet Protocol (VoIP) networks, rather than limiting XMPP users to a separate and distinct network.</p>
<p>Jingle is designed in a modular way so that developers can easily add support for multimedia session types other than voice chat, such as video chat (see &xep0180;), application sharing, file sharing, collaborative editing, whiteboarding, and torrent broadcasting. The transport methods are also modular, so that Jingle implementations can use any appropriate media transport (including proprietary methods not standardized through the XMPP Standards Foundation).</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The protocol defined herein is designed to meet the following requirements:</p>
<ol>
<li>Make it possible to manage a wide variety of peer-to-peer sessions (not limited to voice and video) within XMPP. <note>Possible other content description formats include file sharing, application casting, application sharing, whiteboarding, torrent broadcasting, shared real-time editing, and distributed musical performance, to name but a few.</note>.</li>
<li>Clearly separate the signalling channel (XMPP) from the data channel (e.g., Real-time Transport Protocol as specified in &rfc3550;).</li>
<li>Clearly separate the content description formats (e.g., for voice chat) from the content transport methods (e.g., User Datagram Protocol as specified in &rfc0768;).</li>
<li>Make it possible to manage a wide variety of peer-to-peer sessions (not limited to voice and video) within XMPP.</li>
<li>Clearly separate the signalling channel (XMPP) from the data channel.</li>
<li>Clearly separate the content description formats (e.g., for voice chat) from the content transport methods.</li>
<li>Make it possible to add, modify, and remove content types from an existing session.</li>
<li>Make it relatively easy to implement support for the protocol in standard Jabber/XMPP clients.</li>
<li>Where communication with non-XMPP entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-XMPP network.</li>
</ol>
<p>This document defines the signalling protocol only. Additional documents specify the following:</p>
<ul>
<li><p>Various content description formats (audio, video, etc.) and, where possible, mapping those types to the Session Description Protocol (SDP; see &rfc4566;); examples include &xep0167; and &xep0180;.</p></li>
<li><p>Various content description formats (audio, video, etc.) and, where possible, mapping those types to the Session Description Protocol (SDP; see &rfc4566;); examples include <cite>XEP-0167</cite> and <cite>XEP-0180</cite>.</p></li>
<li><p>Various content transport methods; examples include &xep0176; and &xep0177;.</p></li>
<li><p>Procedures for mapping the Jingle signalling protocol to existing signalling standards such as the IETF's Session Initiation Protocol (SIP; see &rfc3261;) and the ITU's H.323 protocol (see &h323;); these documents are forthcoming.</p></li>
<li><p>Procedures for mapping the Jingle signalling protocol to existing signalling standards such as the IETF's Session Initiation Protocol (SIP) and the ITU's H.323 protocol (see &h323;); these documents are forthcoming.</p></li>
</ul>
</section1>
<section1 topic='Glossary' anchor='glossary'>
@ -837,6 +836,16 @@ PENDING o---------------------+ |
]]></code>
</section2>
</section1>
<section1 topic='History' anchor='history'>
<p>Until Jingle was developed, there existed no widely-adopted standard for initiating and managing peer-to-peer interactions between XMPP entities. Although several large service providers and Jabber client teams had written and implemented their own proprietary XMPP extensions for peer-to-peer signalling (usually only for voice), those technologies were not open and did not always take into account requirements to interoperate with SIP-based technologies. The only existing open protocol was &xep0111;, which made it possible to initiate and manage peer-to-peer sessions, but which did not provide enough of the key signalling semantics to be easily implemented in Jabber/XMPP clients. <note>It is true that TINS made it relatively easy to implement an XMPP-to-SIP gateway; however, in line with the long-time Jabber philosophy of "simple clients, complex servers", it would be better to force complexity onto the server-side gateway and to keep the client as simple as possible.</note></p>
<p>The result was an unfortunate fragmentation within the XMPP community regarding signalling protocols. Essentially, there were two possible approaches to solving the problem:</p>
<ol>
<li>Recommend that all client developers implement a dual-stack (XMPP + SIP) solution.</li>
<li>Define a full-featured protocol for XMPP signalling.</li>
</ol>
<p>Implementation experience indicates that a dual-stack approach may not be feasible on all the computing platforms for which Jabber clients have been written, or even desirable on platforms where it is feasible. <note>For example, one large ISP decided to switch to a pure XMPP approach after having implemented and deployed a dual-stack client for several years.</note> Therefore, it seemed reasonable to define an XMPP signalling protocol that could provide the necessary session management semantics while also making it relatively straightforward to interoperate with existing Internet standards.</p>
<p>As a result of feedback received on <cite>XEP-0111</cite>, the original authors of this document (Joe Hildebrand and Peter Saint-Andre) began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, <note>Google Talk is a messaging and voice chat service and client provided by Google; see &lt;<link url='http://www.google.com/talk/'>http://www.google.com/talk/</link>&gt;.</note> it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified herein is, therefore, substantially equivalent to the original Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the XMPP Standards Foundation's standards process.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Thiago Camargo, Dafydd Harries, Antti Ij&#228;s, Lauri Kaila, Justin Karneges, Jussi Laako, Anthony Minessale, Matt O'Gorman, Rob Taylor, Matt Tucker, Saku Vainio, Brian West, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and (earlier) Jingle <note>Before this specification was accepted as a XMPP Extension Protocol specification, it was discussed on the semi-private &lt;jingle@jabber.org&gt; mailing list; although that list is no longer used (the Standards list is the preferred discussion venue), for historical purposes it is publicly archived at &lt;<link url='http://mail.jabber.org/pipermail/jingle/'>http://mail.jabber.org/pipermail/jingle/</link>&gt;.</note> mailing lists.</p>
</section1>