XEP-xxxx: Jingle WebRTC Transport
Note: Please note that this XEP has been abandoned in preference to parsing the SDP to Jingle and vice versa. See https://github.com/mweibel/sdpToJingle for a draft implementation of an SDP/Jingle parsing library.
This specification defines a Jingle transport method to negotiate media between web browsers or other compatible devices that support WebRTC.
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <email@example.com> mailing list.
Publisher: XMPP Standards Foundation
Last Updated: 2012-02-17
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0166
Superseded By: None
This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.
Relation to XMPP
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Table of Contents
3. Protocol Description
3.1. Transport Initiation
3.2. Target Entity Response
4. WebRTC Service Discovery
5. Deployment Notes
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
8.1. Protocol Namespaces
8.2. Jingle Transport Methods
9. XML Schema
9.1. Transport method
9.2. Transport method
Jingle  defines a framework for negotiating and managing out-of-band multimedia sessions over XMPP. In order to provide a flexible framework, the base Jingle specification omits data transport methods and media session types, requiring separate specifications. Typical peer-to-peer session types include voice chat (see Jingle Audio Content Description Format ) and video chat (see Jingle Video Content Description Format ) which are based on the Real-time Transport Protocol (RTP) and will be suitable for WebRTC.
In order to use WebRTC with the Jingle RTP-ICE Transport Method  requires the developer to translate between the web browser session descriptions and Jingle. This means understanding WebRTC SDP and correct translation into Jingle by the call initiator and back into SDP by the call target. The developer must also create correct RTP-ICE transport candidates at both call ends.
When both paticipants of an audio/video call are both web browsers supporting WebRTC, we already know that the web browsers will transport the media between each other, so it makes for a simpler and neater approach to simply forward the session description messages emitted from the web browser as Jingle session info payload messages instead of translating web browser SDP offer/answer media data into Jingle session descriptions and constructing redundant transport candidates.
This document defines a new Jingle transport method for establishing and managing WebRTC media streams.
The Jingle transport method defined herein is designed to meet the following requirements:
- Make it possible to negotiate media between two XMPP entities contained in web browsers or compatible devices.
- Make it relatively easy for Jingle to take advantage of WebRTC when all call participants are web browsers.
- Provide web application developers a simple way of using Jingle with web browsers without having to understand SDP.
In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the WebRTC transport, it MUST include a <transport/> child element qualified by the 'urn:xmpp:jingle:transports:webrtc:1' namespace.
<content firstname.lastname@example.org' name='audio, video'>
<transport xmlns='urn:xmpp:jingle:transports:webrtc:1' />
As described in XEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:
Once the initiating entity provisionally accepts the session, it:
- MUST initiate a WebRTC session
- MUST exchange the browser SDP session description messages with the target entity using Jingle session-info messages
The target entity MUST attempt a handshake with the initiating entity. it:
- MUST accept the session-info messages and pass the SDP session decription payload to its web browser
Example 3. Initiating and Target Entity exchange session decription payloads with Jingle session-info messages
"messageType" : "OFFER",
"offererSessionId" : "uMHcBZAa8LTylbwAM3RY7IP7LGUPPU1n",
"sdp" : "...................",
"seq" : 1,
"tieBreaker" : 431803714
"answererSessionId" : "kheolvKZYwzioZkCoK7Wxk+bDpp9TNWc",
"messageType" : "ANSWER",
"offererSessionId" : "bL9tAoEyH0NEijbYPJCHbFxAMKypUZJa",
"sdp" : "............",
"seq" : 1
"answererSessionId" : "bL9tAoEyH0NEijbYPJCHbFxAMKypUZJa",
"messageType" : "OK",
"offererSessionId" : "kheolvKZYwzioZkCoK7Wxk+bDpp9TNWc",
When a WebRTC handshake occurs, the remote media becomes available in the web browser of both the initiating and target entities and an event is triggered in both web browsers.
To complete the Jingle call initiation, the target entity MUST send a Jingle element with an action of 'session-accept', when it recieves this event.
<content email@example.com' name='webrtc session'>
<transport xmlns='urn:xmpp:jingle:transports:webrtc:1' />
</iq>The initiating entity then acknowledges the target entity's acceptance:
If an entity supports WebRTC SDP offer / answer model and therefore prefers to receive WebRTC session decription payloads in session-info messages, it MUST advertise support for the "http://www.igniterealtime.org/webrtc/session-info" service discovery feature.
Example 6. Service discovery information request
Example 7. Service discovery information response
This specification applies to both XMPP clients and servers. However, service administrators may wish to deploy an external gateway or internal plugin to a media server in order to simplify the channel or negotiation process. The specifics are outside the scope of this document.
In order to secure the media streams, implementations SHOULD use SRTP protocol to tunnel their media streams through an encrypted session.
This document requires no interaction with IANA;.
Until this specification advances to a status of Draft, its associated namespaces shall be "http://www.igniterealtime.org/webrtc/transport" and "http://www.igniterealtime.org/webrtc/session-info"; upon advancement of this specification, the XMPP Registrar  shall issue more permanent namespaces in accordance with the process defined in Section 4 of XMPP Registrar Function .
The XMPP Registrar shall include "http://www.igniterealtime.org/webrtc/transport" (see Protocol Namespaces) in its registry of Jingle transport methods. The registry submission is as follows:
<desc> A method for exchanging media between WebRTC enabled web browsers or other compatible devices.</desc>
9. XML Schema
9.1 Transport method
9.2 Transport method
Version 0.0.1 (2012-02-17)
First draft. (do)