From 15d1f6bf574e7ca066cf535ac3535ced00b21f92 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 27 Nov 2007 19:37:41 +0000 Subject: [PATCH] 0.21 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1420 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0166.xml | 65 +++++++++++++++++++++++++++++----------------------- 1 file changed, 36 insertions(+), 29 deletions(-) diff --git a/xep-0166.xml b/xep-0166.xml index 8dc3078c..8361fea9 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -26,6 +26,12 @@ &robmcqueen; &seanegan; &hildjj; + + 0.21 + 2007-11-27 + psa +

Further editorial review.

 + 0.20 2007-11-15 @@ -238,9 +244,9 @@ Romeo Juliet

Naturally, more complex scenarios are probable; such scenarios are described in other specifications, such as XEP-0167 for voice chat.

The simplest flow might happens as follows. The example is that of a voice chat (see XEP-0167) initiated by Romeo, where the transport is &xep0177;.

]]> -

The initiator then acknowledges the session-accept message.

+

The initiator then acknowledges the session-accept action.

The other party MUST then acknowledge termination of the session.

]]> @@ -392,7 +398,7 @@ Romeo Juliet

At the most basic level, the process for negotiating a Jingle session is as follows:

  1. One user (the "initator") sends to another user (the "responder") a session request with at least one content type.
    2. -
  2. If the responder wants to proceed, it provisionally accepts the request by sending an IQ result.
    3. +
  3. If the responder wants to proceed, it acknowledges the session initiation request by sending an IQ result.
  4. 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).
  5. These candidates are checked for connectivity.
  6. As soon as the responder finds a candidate over which media can flow, the responder sends to the initiator a "session-accept" action.
    7. @@ -516,10 +522,10 @@ PENDING o---------------------+ |

    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.

    + to='romeo@montague.lit/orchard' + type='error'> @@ -527,10 +533,10 @@ PENDING o---------------------+ | ]]>

    If the responder does not support Jingle, it MUST return a &unavailable; error.

    + to='romeo@montague.lit/orchard' + type='error'> @@ -538,10 +544,10 @@ PENDING o---------------------+ | ]]>

    If the responder wishes to redirect the request to another address, it SHOULD return a &redirect; error.

    + to='romeo@montague.lit/orchard' + type='error'> voicemail@capulet.lit @@ -549,10 +555,10 @@ PENDING o---------------------+ | ]]>

    If the responder is busy, it SHOULD return a &recipient; error along with a Jingle-specific error condition of <busy/>.

    + to='romeo@montague.lit/orchard' + type='error'> @@ -561,10 +567,10 @@ PENDING o---------------------+ | ]]>

    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 <unsupported-content/>.

    + to='romeo@montague.lit/orchard' + type='error'> @@ -573,10 +579,10 @@ PENDING o---------------------+ | ]]>

    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 <unsupported-transports/>.

    + to='romeo@montague.lit/orchard' + type='error'> @@ -585,10 +591,10 @@ PENDING o---------------------+ | ]]>

    If the initiation request was malformed, the responder MUST return a &badrequest; error.

    + to='romeo@montague.lit/orchard' + type='error'> @@ -768,6 +774,7 @@ PENDING o---------------------+ | ]]> +

    Naturally, support MAY also be determined via the dynamic, presence-based profile of Service Discovery defined in XEP-0115.

    @@ -977,7 +984,7 @@ PENDING o---------------------+ | -

    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. 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.

    +

    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. 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.

    The result was an unfortunate fragmentation within the XMPP community regarding signalling protocols. Essentially, there were two possible approaches to solving the problem:

    1. Recommend that all client developers implement a dual-stack (XMPP + SIP) solution.