moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

0.21 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1420 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-11-27 19:37:41 +00:00
parent 6f67dc4cfa
commit 15d1f6bf57
1 changed files with 36 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
xep-0166.xml
View File

@ -26,6 +26,12 @@
&robmcqueen;
&seanegan;
&hildjj;
<revision>
<version>0.21</version>
<date>2007-11-27</date>
<initials>psa</initials>
<remark><p>Further editorial review.</p></remark>
</revision>
<revision>
<version>0.20</version>
<date>2007-11-15</date>
@ -238,9 +244,9 @@ Romeo Juliet
<p>Naturally, more complex scenarios are probable; such scenarios are described in other specifications, such as <cite>XEP-0167</cite> for voice chat.</p>
<p>The simplest flow might happens as follows. The example is that of a voice chat (see <cite>XEP-0167</cite>) initiated by Romeo, where the transport is &xep0177;.</p>
<example caption="Initiator sends session-initiate"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='jingle1'
to='juliet@capulet.lit/balcony'
<iq from='romeo@montague.lit/orchard'
id='jingle1'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns'
action='session-initiate'
@ -295,7 +301,7 @@ Romeo Juliet
</jingle>
</iq>
]]></example>
<p>The initiator then acknowledges the session-accept message.</p>
<p>The initiator then acknowledges the session-accept action.</p>
<example caption="Initiator acknowledges session-accept"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='accept1'
@ -319,9 +325,9 @@ Romeo Juliet
]]></example>
<p>The other party MUST then acknowledge termination of the session.</p>
<example caption="Initiator Acknowledges Termination"><![CDATA[
<iq from='romeo@montague.lit/orchard'
<iq from='romeo@montague.lit/orchard'
id='term1'
to='juliet@capulet.lit/balcony'
to='juliet@capulet.lit/balcony'
type='result'/>
]]></example>
</section1>
@ -392,7 +398,7 @@ Romeo Juliet
<p>At the most basic level, the process for negotiating a Jingle session is as follows:</p>
<ol>
<li>One user (the "initator") sends to another user (the "responder") a session request with at least one content type.</li>
<li>If the responder wants to proceed, it provisionally accepts the request by sending an IQ result.</li>
<li>If the responder wants to proceed, it acknowledges the session initiation request by sending an IQ result.</li>
<li>Both the initiator and responder start exchanging possible transport candidates as quickly as possible (these are sent in quick succession before further negotiation in order to minimize the time required before media data can flow).</li>
<li>These candidates are checked for connectivity.</li>
<li>As soon as the responder finds a candidate over which media can flow, the responder sends to the initiator a "session-accept" action.</li>
@ -516,10 +522,10 @@ PENDING o---------------------+ |
</ul>
<p>If the initiator is unknown to the responder (e.g., via presence subscription or stanza session negotiation) and the responder has a policy of not communicating via Jingle with unknown entities, it SHOULD return a &unavailable; error.</p>
<example caption="Initiator is unknown to responder"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
to='romeo@montague.lit/orchard'
type='error'>
to='romeo@montague.lit/orchard'
type='error'>
<error type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -527,10 +533,10 @@ PENDING o---------------------+ |
]]></example>
<p>If the responder does not support Jingle, it MUST return a &unavailable; error.</p>
<example caption="Receiver does not support Jingle"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
to='romeo@montague.lit/orchard'
type='error'>
to='romeo@montague.lit/orchard'
type='error'>
<error type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -538,10 +544,10 @@ PENDING o---------------------+ |
]]></example>
<p>If the responder wishes to redirect the request to another address, it SHOULD return a &redirect; error.</p>
<example caption="Receiver redirection"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
to='romeo@montague.lit/orchard'
type='error'>
to='romeo@montague.lit/orchard'
type='error'>
<error type='cancel'>
<redirect xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>voicemail@capulet.lit</redirect>
</error>
@ -549,10 +555,10 @@ PENDING o---------------------+ |
]]></example>
<p>If the responder is busy, it SHOULD return a &recipient; error along with a Jingle-specific error condition of &lt;busy/&gt;.</p>
<example caption="Receiver is busy"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
to='romeo@montague.lit/orchard'
type='error'>
to='romeo@montague.lit/orchard'
type='error'>
<error type='wait'>
<recipient-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<busy xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns-errors'/>
@ -561,10 +567,10 @@ PENDING o---------------------+ |
]]></example>
<p>If the responder does not support any of the specified application formats, it MUST return a &feature; error with a Jingle-specific error condition of &lt;unsupported-content/&gt;.</p>
<example caption="Receiver does not support any content description formats"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
to='romeo@montague.lit/orchard'
type='error'>
to='romeo@montague.lit/orchard'
type='error'>
<error type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unsupported-content xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns-errors'/>
@ -573,10 +579,10 @@ PENDING o---------------------+ |
]]></example>
<p>If the responder does not support any of the specified transport methods, it MUST return a &feature; error with a Jingle-specific error condition of &lt;unsupported-transports/&gt;.</p>
<example caption="Receiver does not support any transport methods"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
to='romeo@montague.lit/orchard'
type='error'>
to='romeo@montague.lit/orchard'
type='error'>
<error type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unsupported-transports xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns-errors'/>
@ -585,10 +591,10 @@ PENDING o---------------------+ |
]]></example>
<p>If the initiation request was malformed, the responder MUST return a &badrequest; error.</p>
<example caption="Initiation request malformed"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
to='romeo@montague.lit/orchard'
type='error'>
to='romeo@montague.lit/orchard'
type='error'>
<error type='cancel'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -768,6 +774,7 @@ PENDING o---------------------+ |
</query>
</iq>
]]></example>
<p>Naturally, support MAY also be determined via the dynamic, presence-based profile of Service Discovery defined in <cite>XEP-0115</cite>.</p>
</section1>
<section1 topic='Conformance by Using Protocols' anchor='conformance'>
@ -977,7 +984,7 @@ PENDING o---------------------+ |
</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>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>