From f67efe4588c4075c3d4db9c9c459512e354a7271 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 26 Nov 2008 21:27:54 +0000 Subject: [PATCH] Proposed git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2539 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0166.xml | 16 ++++++++-------- xep-0167.xml | 2 +- xep-0176.xml | 2 +- xep-0177.xml | 2 +- 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/xep-0166.xml b/xep-0166.xml index 5b42cf4de..092cdbfb6 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -7,10 +7,10 @@
Jingle - This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics to be used for a wide variety of application types (e.g., voice chat, video chat, file sharing) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports). + This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics (compatible with SIP) to be used for a wide variety of application types (e.g., voice chat, video chat, file sharing) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports). &LEGALNOTICE; 0166 - Experimental + Proposed Standards Track Standards Council @@ -301,13 +301,13 @@

The purpose of Jingle is to enable one-to-one, peer-to-peer media sessions between XMPP entities, where the negotiation occurs over the XMPP "channel" and the media is exchanged outside the XMPP channel using technologies such as the Real-time Transport Protocol (RTP; &rfc3550;), the User Datagram Protocol (UDP; &rfc0768;), and &ice;.

-

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 adding support for them to the core Jingle layer would introduce unnecessary complexity into a technology that is designed for basic multimedia interaction.

-

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.

-

Jingle is designed in a modular way so that developers can easily add support for multimedia session types other than voice chat, such as 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).

+

One target application for Jingle is simple voice and video chat (see &xep0167;). We stress the word "simple". The purpose of the core Jingle technology 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 adding support for them to the core Jingle layer would introduce unnecessary complexity into a technology that is designed for basic multimedia interaction.

+

In addition, the purpose of Jingle is not to supplant or replace existing Internet 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.

+

Jingle is designed in a modular way so that developers can easily add support for multimedia session types other than voice and video chat, such as 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).

This section provides a friendly introduction to Jingle.

-

In essence, Jingle enables two XMPP entities (e.g., romeo@montague.lit and juliet@capulet.lit) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer takes place outside of XMPP. The simplest session flow is as follows:

+

In essence, Jingle enables two XMPP entities (e.g., romeo@montague.lit and juliet@capulet.lit) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer generally takes place outside of XMPP. A simplified session flow would be as follows:

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

-

The simplest flow might happen as follows. The example is that of a voice chat offer, where the transport method is &xep0176;.

+

The simplest flow might happen as follows. The example is that of a voice chat offer, where the transport method is &xep0176; and the initiator offers several different codec possibilities.

]]> -

After successful transport negotiation (not shown here), the responder accepts the session by sending a session-accept action to the initiator.

+

After successful transport negotiation (not shown here), the responder accepts the session by sending a session-accept action to the initiator (including the negotiated transport details and the subset of offered codecs that the responder supports).

This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints. &LEGALNOTICE; 0167 - Experimental + Proposed Standards Track Standards Council diff --git a/xep-0176.xml b/xep-0176.xml index 2c0e71d60..0b349fc5b 100644 --- a/xep-0176.xml +++ b/xep-0176.xml @@ -11,7 +11,7 @@ This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology defined by the IETF and thus provides robust NAT traversal for media traffic. &LEGALNOTICE; 0176 - Experimental + Proposed Standards Track Standards Council diff --git a/xep-0177.xml b/xep-0177.xml index a6337961b..d5ea9198c 100644 --- a/xep-0177.xml +++ b/xep-0177.xml @@ -10,7 +10,7 @@ This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required. &LEGALNOTICE; 0177 - Experimental + Proposed Standards Track Standards Council