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 standards@xmpp.org mailing list.

Discussion Venue

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.

Conformance Terms

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

WebRTC uses a protocol called JavaScript Session Establishment Protocol (JSEP) [4] that pulls the media negotiation and signaling state machine out of the browser into Javascript. JSEP like Jingle seperates session descriptions from transports and exposes the media negotiation to the application developer making it very compatible with Jingle,.

In order to use WebRTC with the Jingle RTP-ICE Transport Method [5] 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.

2. Requirements

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.

3. Protocol Description

3.1 Transport Initiation

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 child element qualified by the 'urn:xmpp:jingle:transports:webrtc:1**’** namespace.

4. WebRTC Service Discovery

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.

5. Deployment Notes

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.

6. Security Considerations

In order to secure the media streams, implementations SHOULD use SRTP protocol to tunnel their media streams through an encrypted session.

First I was doing a whole lot of parsing which would be unneeded with your XEP.

As soon as I have time, I’ll implement this.

I saw your emails to the jabber (jdev? not sure anymore) mailing list… I hope you can get it through the standardization process in order to gather more clients (also desktop clients) which implement this protocol additionally…

I am aiming to make push it all the way with the XMPP council. Just waiting for the JSEP version of Chrome to confirm before making the proposal formal. How are you planning to use Jingle with MUCs. There is a discussion about this in the WebRTC discussion group. Are you planning on using multi-party jingle (Muji) or something else?

Thanks for spotting the wrong namespace. I also changed the WebRTC transport and session-info namespaces as well because of “xep-xxxx” in them and to make igniterealtime.org the sponsors of the protocol.

Would you be interested in being a co-auther for the Jingle WebRTC Transport XEP ?

I read the Muji spec again and realised, that WebRTC clients do not need the Muji preparation and session description exchange step. The xmpp entity joining the MUC should just initiate Jingle WebRTC sessions with all existing room occupants as recomended in the spec. I am going to implement this next to the OfChat web client.

Dele, just for your information. We (me and LG) are currently testing an option to hide messages with external links automatically (fighting the SEO spam). So this document may disappear time to time after you edit it (it contains links). Then i will remove it from the moderation queue and it will reappear again. Sorry for the possible inconvenience

@Dele: Thanks for changing the ns. About the igniterealtime webrtc namespace: I’m not really sure if that’s the best way to do it. I remember reading that namespaces should all be in the form of urn:xmpp:something:…

Take a look at XEP-0053 for reference (Although I’m not really sure if my guess is correct).

Thanks for asking me to be a co-author. I’d like to do this although I’m not really sure if I have enough spare time.

I was not tracking the payloads and simply passing them on. In practice, the flow from my log files showed offer->answer->ok, we could use the session-accept for the final ok, but any future changes to the ROAP/JSEP SDP offer model will break our code.

In my implementation, I send the session-accept when the onaddstream callback of the PeerConnection object gets called after the remote stream is recieved by the OK SDP message.